Re: [PATCH v5 4/4] hw/arm/virt: Add PL330 DMA controller and connect with SMMU v3

[Peter Maydell]

On Thu, 2 Sept 2021 at 09:23, Li, Chunming <Chunming.Li@verisilicon.com> wrote:
> Eric Auger wrote:
>> On 9/2/21 8:46 AM, Li, Chunming wrote:
>>> Eric Auger wrote:

>>>> Then I think you need to bring a proper motivation behind adding the
>>>> PL330 in machvirt besides a testing purpose.

>>>> After this series you would get a single platform device connected to
>>>> the SMMU, the PL330. What is the actual use case?

>>> The actual use case is this:
>>> 1. We will have a SoC which has SMMUv3 connected with our owned platform
>>>    Video Encoder/Decoder and other IPs
>>> 2. We plan to use SMMUv3 stage 1 for continuous memory allocation
>>>    and stage 2 for memory protection
>>> 3. We are developing our own IP QEMU models now
>>> 4. These models will be connected with SMMUv3 in QEMU
>>> 5. We will use the QEMU board to development IP driver and ensure the driver
>>>    can work well with Linux SMMU and IOMMU framework

>> I see and I understand your use case for system modeling purpose.
>>
>> This raises few questions/comments though.
>> - supporting platform device protection from the vIOMMU/ARM makes sense
>> to me globally. But above use case does not justify (to me) the
>> introduction of PL330 in machvirt because it would be just for testing
>> purpose. Peter may validate/invalidate though. Instead I think you
>> should try to illustrate this feature with DMA capable platform devices
>> such virtio-net and virtio-block sysbus devices as a counterpart of
>> their PCIe flavour.
>
> Thanks for your suggestion. I will try virtio-net and virtio-block sysbus
> devices in next step.
> But I hope to keep PL330 because it's not just for testing purpose.
> It's a good example to show how to connect platform devices with SMMUv3 based
> on this patch.
> I assume other developer may have same requirement.

I agree with Eric here that the 'virt' board is not the right place
to put this PL330. The 'virt' board is not intended as a dumping
ground or experimental testbed for every possible arm device or
system configuration -- we try to keep it at least reasonably
targeted towards the "generic virtual platform or VM" usecase.

The "sbsa-ref" platform is intended to look more like "real hardware".
It's possible that "memory mapped hardware that sits behind an SMMU"
is something that you would see on the sort of system that sbsa-ref
is trying to model. I've cc'd Leif who would have a better idea about
that.

thanks
-- PMM