> -----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/
Thanks,
Shameer
