> From: Alex Williamson <alex.williamson@redhat.com> > 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
On Thu, 28 Apr 2022 03:21:45 +0000 "Tian, Kevin" <kevin.tian@intel.com> wrote: > > From: Alex Williamson <alex.williamson@redhat.com> > > 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. > 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, Alex
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@intel.com> wrote: > > > > From: Alex Williamson <alex.williamson@redhat.com> > > > 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. > > > 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. 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 :|
> From: Daniel P. Berrangé <berrange@redhat.com> > 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@intel.com> wrote: > > > > > > From: Alex Williamson <alex.williamson@redhat.com> > > > > 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
© 2016 - 2024 Red Hat, Inc.