> 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 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. 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? Thanks Kevin
