Re: [PATCH v4 06/27] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

[Nicolin Chen <nicolinc@nvidia.com>]

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.

Perhaps we could add a couple of lines to the comments.

Thanks
Nicolin