RE: [RFC 00/18] vfio: Adopt iommufd

From: Alex Williamson <alex.williamson(a)redhat.com&gt; 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.