> -----Original Message----- > From: Jason Gunthorpe <[email protected]> > Sent: Thursday, February 6, 2025 5:59 PM > To: Daniel P. Berrangé <[email protected]> > Cc: Shameerali Kolothum Thodi > <[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]; [email protected] > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable > nested SMMUv3 > > On Thu, Feb 06, 2025 at 05:54:57PM +0000, Daniel P. Berrangé wrote: > > > > We shouldn't assume any VFIO device exists in the QEMU cnofig at the > time > > > > we realize the virtual ssmu. I expect the SMMU may be cold plugged, > while > > > > the VFIO devices may be hot plugged arbitrarly later, and we should > have > > > > the association initialized the SMMU is realized. > > > > > > This is not supported kernel side, you can't instantiate a vIOMMU > > > without a VFIO device that uses it. For security. > > > > What are the security concerns here ? > > You should not be able to open iommufd and manipulate iommu HW that > you don't have a VFIO descriptor for, including creating physical > vIOMMU resources, allocating command queues and whatever else. > > Some kind of hot plug smmu would have to create a vSMMU without any > kernel backing and then later bind it to a kernel implementation.
Not sure I get the problem with associating vSMMU with a pSMMU. Something like an iommu instance id mentioned before, -device arm-smmuv3-accel,id=smmuv2,bus=pcie.2,host-smmu=iommu.1 This can realize the vSMMU without actually creating a vIOMMU in kernel. And when the dev gets attached/realized, check (GET_HW_INFO)the specified iommu instance id matches or not. Or the concern here is exporting an iommu instance id to user space? Thanks, Shameer
