On Thu, Sep 18, 2025 at 06:31:43AM -0700, Shameer Kolothum wrote:
> > > > @@ -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?
smmuv3_accel_find_add_as() is per instance. So, it wouldn't share.
Even smmuv3_accel_init() wouldn't work.
If SMMUBaseClass isn't a good place, (I haven't tested but..) can
we do address_space_init() in the VMS? I see virt.c calling the
memory_region_init(), so perhaps we could init the as_sysmem there
and pass it in to each vSMMU instance.
Nicolin
