On 10/20/25 8:59 PM, Shameer Kolothum wrote:
>
>> -----Original Message-----
>> From: Nicolin Chen <[email protected]>
>> Sent: 20 October 2025 19:25
>> To: Eric Auger <[email protected]>
>> Cc: Shameer Kolothum <[email protected]>; qemu-
>> [email protected]; [email protected]; [email protected];
>> Jason Gunthorpe <[email protected]>; [email protected];
>> [email protected]; Nathan Chen <[email protected]>; Matt Ochs
>> <[email protected]>; [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]
>> Subject: Re: [PATCH v4 06/27] hw/arm/smmuv3-accel: Restrict accelerated
>> SMMUv3 to vfio-pci endpoints with iommufd
>>
>> On Mon, Oct 20, 2025 at 06:31:38PM +0200, Eric Auger wrote:
>>> On 9/29/25 3:36 PM, Shameer Kolothum wrote:
>>>> + /*
>>>> + * We return the system address for vfio-pci devices(with iommufd as
>>>> + * backend) so that the VFIO core can set up Stage-2 (S2) mappings for
>>>> + * guest RAM. This is needed because, in the accelerated SMMUv3
>> case,
>>>> + * the host SMMUv3 runs in nested (S1 + S2) mode where the guest
>>>> + * manages its own S1 page tables while the host manages S2.
>>>> + *
>>>> + * We are using the global &address_space_memory here, as this will
>> ensure
>>>> + * same system address space pointer for all devices behind the
>> accelerated
>>>> + * SMMUv3s in a VM. That way VFIO/iommufd can reuse a single IOAS
>> ID in
>>>> + * iommufd_cdev_attach(), allowing the Stage-2 page tables to be
>> shared
>>>> + * within the VM instead of duplicating them for every SMMUv3
>> instance.
>>>> + */
>>>> + if (vfio_pci) {
>>>> + return &address_space_memory;
>>> From that comment one understands the need of a single and common AS.
>>> However it is not obvious why it shall be
>>>
>>> &address_space_memory and not an AS created on purpose.
>> We tried creating an AS, but it was not straightforward to share across vSMMU
>> instances, as most of the structures are per vSMMU.
>>
>> Only SMMUv3Class seems to be shared across vSMMU instances, but it
>> doesn't seem to be the good place to hold an AS pointer either.
>>
>> The global @address_space_memory is provisioned as the system AS, so it's
>> easy to use.
> We had discussed this previously here,
> https://lore.kernel.org/qemu-devel/aJKn650gOGQh2whD@Asurada-Nvidia/
Thank you for the pointer. I definitively missed that thread. Seems
Peter was not very keen either to use the address_space_memory. Why
can't we use a global variable in smmu-accel.c ? in hw/vfio/container.c
there is a list of VFIOAddressSpace for instance.
Is there anything wrong doing that?
Thanks
Eric
Eric
>
> Thanks,
> Shameer
>
