> From: Daniel P. Berrangé <berrange@xxxxxxxxxx> > Sent: Friday, April 29, 2022 12:20 AM > > On Thu, Apr 28, 2022 at 08:24:48AM -0600, Alex Williamson wrote: > > On Thu, 28 Apr 2022 03:21:45 +0000 > > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > > > Sent: Wednesday, April 27, 2022 12:22 AM > > > > > > > > > > > > My expectation would be that libvirt uses: > > > > > > > > > > > > -object iommufd,id=iommufd0,fd=NNN > > > > > > -device vfio-pci,fd=MMM,iommufd=iommufd0 > > > > > > > > > > > > Whereas simple QEMU command line would be: > > > > > > > > > > > > -object iommufd,id=iommufd0 > > > > > > -device vfio-pci,iommufd=iommufd0,host=0000:02:00.0 > > > > > > > > > > > > The iommufd object would open /dev/iommufd itself. Creating an > > > > > > implicit iommufd object is someone problematic because one of the > > > > > > things I forgot to highlight in my previous description is that the > > > > > > iommufd object is meant to be shared across not only various vfio > > > > > > devices (platform, ccw, ap, nvme, etc), but also across subsystems, > ex. > > > > > > vdpa. > > > > > > > > > > Out of curiosity - in concept one iommufd is sufficient to support all > > > > > ioas requirements across subsystems while having multiple > iommufd's > > > > > instead lose the benefit of centralized accounting. The latter will also > > > > > cause some trouble when we start virtualizing ENQCMD which > requires > > > > > VM-wide PASID virtualization thus further needs to share that > > > > > information across iommufd's. Not unsolvable but really no gain by > > > > > adding such complexity. So I'm curious whether Qemu provide > > > > > a way to restrict that certain object type can only have one instance > > > > > to discourage such multi-iommufd attempt? > > > > > > > > I don't see any reason for QEMU to restrict iommufd objects. The > QEMU > > > > philosophy seems to be to let users create whatever configuration they > > > > want. For libvirt though, the assumption would be that a single > > > > iommufd object can be used across subsystems, so libvirt would never > > > > automatically create multiple objects. > > > > > > I like the flexibility what the objection approach gives in your proposal. > > > But with the said complexity in mind (with no foreseen benefit), I wonder > > > > What's the actual complexity? Front-end/backend splits are very common > > in QEMU. We're making the object connection via name, why is it > > significantly more complicated to allow multiple iommufd objects? On > > the contrary, it seems to me that we'd need to go out of our way to add > > code to block multiple iommufd objects. Probably it's just a hypothetical concern when I thought about the need of managing certain global information (e.g. PASID virtualization) cross iommufd's down the road. With your and Daniel's replies I think we'll first try to follow the common practice in Qemu first given there are more positive reasons to do so than the hypothetical concern itself. > > > > > whether an alternative approach which treats iommufd as a global > > > property instead of an object is acceptable in Qemu, i.e.: > > > > > > -iommufd on/off > > > -device vfio-pci,iommufd,[fd=MMM/host=0000:02:00.0] > > > > > > All devices with iommufd specified then implicitly share a single iommufd > > > object within Qemu. > > > > QEMU requires key-value pairs AFAIK, so the above doesn't work, then > > we're just back to the iommufd=on/off. > > > > > This still allows vfio devices to be specified via fd but just requires Libvirt > > > to grant file permission on /dev/iommu. Is it a worthwhile tradeoff to be > > > considered or just not a typical way in Qemu philosophy e.g. any object > > > associated with a device must be explicitly specified? > > > > Avoiding QEMU opening files was a significant focus of my alternate > > proposal. Also note that we must be able to support hotplug, so we > > need to be able to dynamically add and remove the iommufd object, I > > don't see that a global property allows for that. Implicit > > associations of devices to shared resources doesn't seem particularly > > desirable to me. Thanks, > > Adding new global properties/options is rather an anti-pattern for QEMU > these days. Using -object is the right approach. If you only want to > allow for one of them, just document this requirement. We've got other > objects which are singletons like all the confidential guest classes > for each arch. > Good to know such last resort. As said we'll try to avoid this restriction and follow Alex's proposal unless there are unexpectedly unreasonable complexities arising later. Thanks Kevin
