RE: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3

Fri, 31 Jan 2025 06:41:13 -0800 


> -----Original Message-----
> From: Jason Gunthorpe <[email protected]>
> Sent: Friday, January 31, 2025 2:24 PM
> To: Shameerali Kolothum Thodi <[email protected]>
> Cc: Daniel P. Berrangé <[email protected]>; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> Linuxarm <[email protected]>; Wangzhou (B)
> <[email protected]>; jiangkunkun <[email protected]>;
> Jonathan Cameron <[email protected]>;
> [email protected]; Nathan Chen <[email protected]>
> Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable
> nested SMMUv3
> 
> On Fri, Jan 31, 2025 at 09:33:16AM +0000, Shameerali Kolothum Thodi
> wrote:
> 
> > And Qemu does some checking to make sure that the device is indeed
> associated
> > with the specified phys-smmuv3.  This can be done going through the
> sysfs path checking
> > which is what I guess libvirt is currently doing to populate the topology.
> So basically
> > Qemu is just replicating that to validate again.
> 
> I would prefer that iommufd users not have to go out to sysfs..
> 
> > Or another option is extending the IOMMU_GET_HW_INFO IOCTL to
> return the phys
> > smmuv3 base address which can avoid going through the sysfs.
> 
> It also doesn't seem great to expose a physical address. But we could
> have an 'iommu instance id' that was a unique small integer?

Ok. But how the user space can map that to the device?

Something like,
/sys/bus/pci/devices/0000:7d:00.1/iommu/instance.X ?

Thanks,
Shameer























					Reply via email to