Re: [RFC PATCH 2/5] conf: Add an iommufd member struct to virDomainIOMMUDef

> > On 5/20/2025 6:01 AM, Daniel P. Berrangé wrote: >>> Add support for an "iommufd" virDomainIOMMUDef member that will be >>> translated to a qemu "-object iommufd" command line argument. This >>> iommufd struct has an "id" member to specify the iommufd object id >>> that can be associated with a passthrough device, and an "fd" >>> member to specify the fd for externally opening the /dev/iommu and >>> VFIO cdev by a management layer. >>> >>> @@ -28310,6 +28406,16 @@ virDomainIOMMUDefFormat(virBuffer *buf, >>> virXMLFormatElement(&childBuf, "driver", &driverAttrBuf, NULL); >>> + if (iommu->iommufd) { >>> + virBufferAddLit(&childBuf, "<iommufd>\n"); >>> + virBufferAdjustIndent(&childBuf, 2); >>> + virBufferAsprintf(&childBuf, "<id>%s</id>\n", iommu->iommufd->id); >>> + if (iommu->iommufd->fd) >>> + virBufferAsprintf(&childBuf, "<fd>%s</fd>\n", iommu->iommufd->fd); >> I'm not convinced we should be exposing the QEMU "id" in the XML. >> It is an identifier libvirt uses internally for configuring >> QEMU, but I don't see a reason why the end user needs to control >> its name. I'm similarly not sure we should expose an FD to >> users eitherm, just use that internally when talking to QEMU. >> >> IOW, why aren't we just having "iommu='yes'" as an attribute >> on the <iommu> device, avoiding all the logic below that >> tries to force all devices to use the same configuration. > That makes sense - I will simply have an attribute like "iommufd='yes'" as > an attribute in the next revision instead of having users specify the > iommufd id themselves. > > As for exposing an FD to users, this is meant to mirror the qemu > implementation where users can specify the FD string [0], so I think we > should keep this part as-is. The FD passing functionality exposed by QEMU is targetted at mgmt apps like libvirt, which apply sandboxing to QEMU, and thus need to pass in pre-opened FDs. Most of the time, this is not something that libvirt will expose to its own API/XML users, as FDs are a very low level concept that is backend implementation specific.