On 11/6/2025 10:49 AM, Ján Tomko wrote:
Implement a new iommufd attribute under hostdevs' PCI
subsystem driver that can be used to specify associated
iommufd object when launching a qemu VM.
This does not specify which iommufd object it is, just to use the
default one.
It's perfect for now, we might need a different element if using
anything else than iommufd0 starts making sense.
Also, I think it should fine not to expose the object in the XML since
it has configurable attributes now:
# qemu-system-x86_64 -object iommufd,?
iommufd options:
fd=<string>
Noted, will re-visit if anything else other than iommufd0 makes sense.
Signed-off-by: Nathan Chen <[email protected]>
---
docs/formatdomain.rst | 8 ++++++++
src/conf/device_conf.c | 9 +++++++++
src/conf/device_conf.h | 1 +
src/conf/schemas/basictypes.rng | 5 +++++
src/qemu/qemu_command.c | 19 +++++++++++++++++++
5 files changed, 42 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 34dc9c3af7..a5c69dbcf4 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -4845,6 +4845,7 @@ or:
device; if PCI ROM loading is disabled through this attribute,
attempts to
tweak the loading process further using the ``bar`` or ``file``
attributes
will be rejected. :since:`Since 4.3.0 (QEMU and KVM only)`.
+
``address``
The ``address`` element for USB devices has a ``bus`` and ``device``
attribute to specify the USB bus and device number the device
appears at on
@@ -4885,6 +4886,13 @@ or:
found is "problematic" in some way, the generic vfio-pci driver
similarly be forced.
+ The ``<driver>`` element's ``iommufd`` attribute is used to specify
+ using the iommufd interface to propagate DMA mappings to the kernel,
+ instead of legacy VFIO. When the attribute is present, an iommufd
+ object will be created by the resulting qemu command. Libvirt will
+ open the /dev/iommu and VFIO device cdev, passing the associated
+ file descriptor numbers to the qemu command.
+
Should we resurrect the old attribute and use:
<driver name="iommufd"/>
The idea being that later in time, when it will no longer make sense
to use "legacy" VFIO, we will retire it again.
Also, referring to it as "legacy" is both premature (since iommufd does not
have the feature parity yet) and confusing in the passage of time.
I think it would be better to leave it as-is for now, since there are
variant VFIO drivers besides vfio-pci that could be assigned to the
driver name attribute in tandem with enabling iommufd.
(Note: :since:`Since 1.0.5`, the ``name`` attribute has been
described to be used to select the type of PCI device assignment
("vfio", "kvm", or "xen"), but those values have been mostly
diff --git a/src/conf/device_conf.c b/src/conf/device_conf.c
index c278b81652..88979ecc39 100644
--- a/src/conf/device_conf.c
+++ b/src/conf/device_conf.c
@@ -60,6 +60,8 @@ int
virDeviceHostdevPCIDriverInfoParseXML(xmlNodePtr node,
virDeviceHostdevPCIDriverInfo
*driver)
{
+ virTristateBool iommufd;
+ driver->iommufd = false;
if (virXMLPropEnum(node, "name",
virDeviceHostdevPCIDriverNameTypeFromString,
VIR_XML_PROP_NONZERO,
@@ -67,6 +69,10 @@ virDeviceHostdevPCIDriverInfoParseXML(xmlNodePtr node,
return -1;
}
+ if (virXMLPropTristateBool(node, "iommufd", VIR_XML_PROP_NONE,
&iommufd) < 0)
+ return -1;
+ virTristateBoolToBool(iommufd, &driver->iommufd);
Storing this as 'bool' is losing information. We need to be able to tell
whether iommufd was not used because the user did not specify it or
whether it was not used because the user explicitly said no for future
compatibility reasons.
That makes sense, I will update it to use virTristateBool instead in the
next revision.
-Nathan
