> -----Original Message-----
> From: Shameer Kolothum
> Sent: 17 September 2025 19:53
> To: Nicolin Chen <[email protected]>; Shameer Kolothum
> <[email protected]>
> Cc: [email protected]; [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]
> Subject: RE: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict
> accelerated SMMUv3 to vfio-pci endpoints with iommufd
>
>
>
> > -----Original Message-----
> > From: Nicolin Chen <[email protected]>
> > Sent: 17 September 2025 19:45
> > To: Shameer Kolothum <[email protected]>
> > Cc: [email protected]; [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]; Shameer Kolothum
> > <[email protected]>
> > Subject: Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict
> > accelerated
> > SMMUv3 to vfio-pci endpoints with iommufd
> >
> > On Tue, Sep 16, 2025 at 11:33:21AM +0100, Shameer Kolothum wrote:
> > > > I found a new problem here that we initialize new as_sysmem per
> > > > VFIO device. So, sdevs would return own individual AS pointers
> > > > here at this get_address_space function, although they point to
> > > > the same system address space.
> > > >
> > > > Since address space pointers are returned differently for VFIO
> > > > devices, this fails to reuse ioas_id in iommufd_cdev_attach(), and
> > > > ends up with allocating a new ioas for each device.
> > > >
> > > > I think we can try the following change to make sure all accel
> > > > linked VFIO devices would share the same ioas_id, though I am not
> > > > sure if SMMUBaseClass is the right place to go. Please take a
> > > > look.
> > >
> > > Ok. I think it is better to move that to SMMUv3AccelState and call
> > > address_space_init() in smmuv3_accel_init() instead. Something like
> > > below. Please take a look and let me know.
> >
> > [...]
> >
> > > @@ -37,7 +37,6 @@ typedef struct SMMUS1Hwpt {
> > >
> > > typedef struct SMMUv3AccelDevice {
> > > SMMUDevice sdev;
> > > - AddressSpace as_sysmem;
> > > HostIOMMUDeviceIOMMUFD *idev;
> > > SMMUS1Hwpt *s1_hwpt;
> > > SMMUViommu *viommu;
> > > @@ -48,6 +47,7 @@ typedef struct SMMUv3AccelDevice { typedef struct
> > > SMMUv3AccelState {
> > > MemoryRegion root;
> > > MemoryRegion sysmem;
> > > + AddressSpace as_sysmem;
> > > SMMUViommu *viommu;
> > > struct iommu_hw_info_arm_smmuv3 info; } SMMUv3AccelState;
> >
> > That's changing from an ioas_id per VFIO device to an ioas_id per
> > vSMMU instance, right? I think it's still not enough.
> >
> > All vSMMU instances could share the same ioas_id. That is why I put in
> > the SMMUBaseClass as it's shared structure across vSMMUs.
>
> Ah..you mean it is basically per VM then. Got it.
Regarding using SMMUBaseClass for this, it looks like ObjectClass normally holds
function pointers. Eric has made a similar observation elsewhere in this series.
@Eric, any suggestions?
Is use of &address_space_memory directly in smmuv3_accel_find_add_as() a
complete
no-go, given we are talking about having the system address space for all the
SMMUv3
accelerated devices here?
Thanks,
Shameer
