On Thu, Feb 06, 2025 at 01:58:43PM -0400, Jason Gunthorpe wrote: > 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.
Ok, so if we give the info about the vSMMU <-> pSMMU binding to QEMU upfront, it can delay using it until the point where the kernel accepts it. This at least gives a clear design to applications outside QEMU, and hides the low level impl details to inside QEMU. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
