On 5/30/2025 6:47 AM, Daniel P. Berrangé wrote:
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.
I see, I will look into implementing logic to pre-open iommufd FDs from
libvirt, and keep this un-exposed to the API/XML users. Pre-opening
these FDs may come into play in resolving the permissions issues I was
encountering in the cover letter as well.
Thanks,
Nathan
