On 3/16/26 3:04 AM, Cédric Le Goater wrote:
Hello Pierrick,
On 3/15/26 08:08, Pierrick Bouvier wrote:
As pointed in c1139fa4 "vfio/iommufd: Remove CONFIG_IOMMUFD usage",
iommufd presence can be detected at runtime (through /dev/iommufd)
Note that the device name is "/dev/iommu/".
Oops, you're right, I'll fix the name.
The overall flow is a slightly more complex. If IOMMUFD is not
supported by the kernel, QEMU will fail when attemting to attach
to the device. This failure occurs before the device is connected
to the IOMMUFD host backend and QEMU will report an error such as :
qemu-XYZ: -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0: vfio
0000:01:00.0: vfio/sys/bus/pci/devices/0000:01:00.0/vfio-dev: failed to load
"/sys/bus/pci/devices/0000:01:00.0/vfio-dev/vfio0/dev
But this is a kernel-side issue.
Ok, details are a bit blurry in my head to be honest, as it was 9 months
ago. After checking again, both CONFIG_IOMMUFD and
CONFIG_VFIO_DEVICE_CDEV are needed and absence of one of them will
produce the message above.
https://docs.kernel.org/driver-api/vfio.html#vfio-device-cdev
I had other iommu error messages but it was related to iommu groups
issue, which is a different topic.
and
we don't need to isolate this at build time.
It's much (much) more simple to expose this inconditionally
we should better explain the motivation behind this approach.
compared to
build dynamically properties arrays.
and that would be an alternative that we don't want to explore.
Let's come back to the proposal. Currently, when the QEMU platform
doesn't support IOMMUFD (i.e no support for the backend), QEMU reports
at runtime :
qemu-XYZ...: invalid object type: iommufd
As a consequence, the vfio-pci device doesn't expose the "iommufd"
property when the backend IOMMUFD is not available.
However, the additional filtering on the vfio-pci properties based
on CONFIG_IOMMUFD seems unnecessary. Instead the "iommufd" property
could always be exposed, whether or not the QEMU build includes IOMMUFD
support (kernel support is another topic). If the property is used
in an environment where IOMMUFD is unsupported, QEMU will simply
fail to create the IOMMUFD object.
Could you please rephrase the commit log with some of this information ?
Sure, how about:
{{{
hw/vfio: eradicate CONFIG_IOMMU from sources
This commit removes usage of CONFIG_IOMMU in hw/vfio sources, exposing
inconditionally iommufd related properties, which are declared
statically (in const arrays). The alternative to expose them dynamically
is more complex and requires boilerplate to set properties at runtime,
with set_* callbacks and added logic to check if iommufd backend is
available, with no obvious benefit.
One difference is that user will have a different error message when
trying to attach a vfio device on a platform not supporting iommufd.
Instead of:
```
$ qemu-system-* -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0
invalid object type: iommufd
```
QEMU will try to attach device and error will be reported as:
```
-device vfio-pci,host=0000:01:00.0,iommufd=iommufd0:
vfio 0000:01:00.0: vfio/sys/bus/pci/devices/0000:01:00.0/vfio-dev:
failed to load "/sys/bus/pci/devices/0000:01:00.0/vfio-dev/vfio0/dev
```
Note: This second error can already happen if user's kernel does not
have CONFIG_IOMMUFD or CONFIG_VFIO_DEVICE_CDEV support, but QEMU has it.
}}}
Anything you would like to add?
Thanks,
C.
Writing my answer and seeing current behavior, I wonder if we could not
have better error messages simply by checking if /dev/iommu exists when
setting the iommufd property of vfio-pci device or when realizing the
iommufd object (-object iommufd,id=iommufd0). For the latter, I need to
double check order or initialization/realization as it might be tricky
to catch before setting accessing vfio-dev/vfio0/dev.
$ qemu-system-* -object iommufd,id=iommufd0
can't create iommufd object: /dev/iommu not found
Is your kernel config missing CONFIG_IOMMUFD?
As well, we could report "Is your kernel config missing
CONFIG_VFIO_DEVICE_CDEV?" on the error mentioned in commit message.
And while we're at it, in case we report one of those errors, we could
check target_arch(), and if it's not one supporting actively support
iommufd, say to the user "Linux does not support iommufd on this
platform" instead of "Is your kernel missing X or Y?".
What do you think?
Regards,
Pierrick
