As pointed in c1139fa4 "vfio/iommufd: Remove CONFIG_IOMMUFD usage",
iommufd presence can be detected at runtime (through /dev/iommufd) and
we don't need to isolate this at build time.
It's much (much) more simple to expose this inconditionally compared to
build dynamically properties arrays.
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
---
hw/vfio/ap.c | 9 ---------
hw/vfio/ccw.c | 9 ---------
hw/vfio/pci.c | 11 -----------
3 files changed, 29 deletions(-)
diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
index e58a0169af9..856fa2678cd 100644
--- a/hw/vfio/ap.c
+++ b/hw/vfio/ap.c
@@ -11,7 +11,6 @@
*/
#include "qemu/osdep.h"
-#include CONFIG_DEVICES /* CONFIG_IOMMUFD */
#include <linux/vfio.h>
#include <sys/ioctl.h>
#include "qapi/error.h"
@@ -279,10 +278,8 @@ static void vfio_ap_unrealize(DeviceState *dev)
static const Property vfio_ap_properties[] = {
DEFINE_PROP_STRING("sysfsdev", VFIOAPDevice, vdev.sysfsdev),
-#ifdef CONFIG_IOMMUFD
DEFINE_PROP_LINK("iommufd", VFIOAPDevice, vdev.iommufd,
TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
-#endif
};
static void vfio_ap_reset(DeviceState *dev)
@@ -320,21 +317,17 @@ static void vfio_ap_instance_init(Object *obj)
vbasedev->mdev = true;
}
-#ifdef CONFIG_IOMMUFD
static void vfio_ap_set_fd(Object *obj, const char *str, Error **errp)
{
vfio_device_set_fd(&VFIO_AP_DEVICE(obj)->vdev, str, errp);
}
-#endif
static void vfio_ap_class_init(ObjectClass *klass, const void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
device_class_set_props(dc, vfio_ap_properties);
-#ifdef CONFIG_IOMMUFD
object_class_property_add_str(klass, "fd", NULL, vfio_ap_set_fd);
-#endif
dc->vmsd = &vfio_ap_vmstate;
dc->desc = "VFIO-based AP device assignment";
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
@@ -347,11 +340,9 @@ static void vfio_ap_class_init(ObjectClass *klass, const void *data)
object_class_property_set_description(klass, /* 3.1 */
"sysfsdev",
"Host sysfs path of assigned device");
-#ifdef CONFIG_IOMMUFD
object_class_property_set_description(klass, /* 9.0 */
"iommufd",
"Set host IOMMUFD backend device");
-#endif
}
static const TypeInfo vfio_ap_info = {
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index 2251facb356..c66f42a13c2 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -15,7 +15,6 @@
*/
#include "qemu/osdep.h"
-#include CONFIG_DEVICES /* CONFIG_IOMMUFD */
#include <linux/vfio.h>
#include <linux/vfio_ccw.h>
#include <sys/ioctl.h>
@@ -647,10 +646,8 @@ static void vfio_ccw_unrealize(DeviceState *dev)
static const Property vfio_ccw_properties[] = {
DEFINE_PROP_STRING("sysfsdev", VFIOCCWDevice, vdev.sysfsdev),
DEFINE_PROP_BOOL("force-orb-pfch", VFIOCCWDevice, force_orb_pfch, false),
-#ifdef CONFIG_IOMMUFD
DEFINE_PROP_LINK("iommufd", VFIOCCWDevice, vdev.iommufd,
TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
-#endif
DEFINE_PROP_CCW_LOADPARM("loadparm", CcwDevice, loadparm),
};
@@ -679,12 +676,10 @@ static void vfio_ccw_instance_init(Object *obj)
DEVICE(vcdev), true);
}
-#ifdef CONFIG_IOMMUFD
static void vfio_ccw_set_fd(Object *obj, const char *str, Error **errp)
{
vfio_device_set_fd(&VFIO_CCW(obj)->vdev, str, errp);
}
-#endif
static void vfio_ccw_class_init(ObjectClass *klass, const void *data)
{
@@ -692,9 +687,7 @@ static void vfio_ccw_class_init(ObjectClass *klass, const void *data)
S390CCWDeviceClass *cdc = S390_CCW_DEVICE_CLASS(klass);
device_class_set_props(dc, vfio_ccw_properties);
-#ifdef CONFIG_IOMMUFD
object_class_property_add_str(klass, "fd", NULL, vfio_ccw_set_fd);
-#endif
dc->vmsd = &vfio_ccw_vmstate;
dc->desc = "VFIO-based subchannel assignment";
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
@@ -713,11 +706,9 @@ static void vfio_ccw_class_init(ObjectClass *klass, const void *data)
object_class_property_set_description(klass, /* 3.0 */
"force-orb-pfch",
"Force unlimited prefetch");
-#ifdef CONFIG_IOMMUFD
object_class_property_set_description(klass, /* 9.0 */
"iommufd",
"Set host IOMMUFD backend device");
-#endif
object_class_property_set_description(klass, /* 9.2 */
"loadparm",
"Define which devices that can be used for booting");
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 94c174a773f..df617f1fe46 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -19,7 +19,6 @@
*/
#include "qemu/osdep.h"
-#include CONFIG_DEVICES /* CONFIG_IOMMUFD */
#include <linux/vfio.h>
#include <sys/ioctl.h>
@@ -3471,9 +3470,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
~vdev->host.slot || ~vdev->host.function)) {
error_setg(errp, "No provided host device");
error_append_hint(errp, "Use -device vfio-pci,host=DDDD:BB:DD.F "
-#ifdef CONFIG_IOMMUFD
"or -device vfio-pci,fd=DEVICE_FD "
-#endif
"or -device vfio-pci,sysfsdev=PATH_TO_DEVICE\n");
return;
}
@@ -3816,22 +3813,18 @@ static const Property vfio_pci_properties[] = {
qdev_prop_nv_gpudirect_clique, uint8_t),
DEFINE_PROP_OFF_AUTO_PCIBAR("x-msix-relocation", VFIOPCIDevice, msix_relo,
OFF_AUTO_PCIBAR_OFF),
-#ifdef CONFIG_IOMMUFD
DEFINE_PROP_LINK("iommufd", VFIOPCIDevice, vbasedev.iommufd,
TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
-#endif
DEFINE_PROP_BOOL("skip-vsc-check", VFIOPCIDevice, skip_vsc_check, true),
DEFINE_PROP_UINT16("x-vpasid-cap-offset", VFIOPCIDevice,
vpasid_cap_offset, 0),
};
-#ifdef CONFIG_IOMMUFD
static void vfio_pci_set_fd(Object *obj, const char *str, Error **errp)
{
VFIOPCIDevice *vdev = VFIO_PCI_DEVICE(obj);
vfio_device_set_fd(&vdev->vbasedev, str, errp);
}
-#endif
static void vfio_pci_class_init(ObjectClass *klass, const void *data)
{
@@ -3840,9 +3833,7 @@ static void vfio_pci_class_init(ObjectClass *klass, const void *data)
device_class_set_legacy_reset(dc, vfio_pci_reset);
device_class_set_props(dc, vfio_pci_properties);
-#ifdef CONFIG_IOMMUFD
object_class_property_add_str(klass, "fd", NULL, vfio_pci_set_fd);
-#endif
dc->vmsd = &vfio_cpr_pci_vmstate;
dc->desc = "VFIO-based PCI device assignment";
pdc->realize = vfio_pci_realize;
@@ -3944,11 +3935,9 @@ static void vfio_pci_class_init(ObjectClass *klass, const void *data)
"vf-token",
"Specify UUID VF token. Required for VF when PF is owned "
"by another VFIO driver");
-#ifdef CONFIG_IOMMUFD
object_class_property_set_description(klass, /* 9.0 */
"iommufd",
"Set host IOMMUFD backend device");
-#endif
object_class_property_set_description(klass, /* 9.1 */
"x-device-dirty-page-tracking",
"Disable device dirty page tracking and use "
--
2.47.3Hello 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/".
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.
> 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 ?
Thanks,
C.
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> ---
> hw/vfio/ap.c | 9 ---------
> hw/vfio/ccw.c | 9 ---------
> hw/vfio/pci.c | 11 -----------
> 3 files changed, 29 deletions(-)
>
> diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
> index e58a0169af9..856fa2678cd 100644
> --- a/hw/vfio/ap.c
> +++ b/hw/vfio/ap.c
> @@ -11,7 +11,6 @@
> */
>
> #include "qemu/osdep.h"
> -#include CONFIG_DEVICES /* CONFIG_IOMMUFD */
> #include <linux/vfio.h>
> #include <sys/ioctl.h>
> #include "qapi/error.h"
> @@ -279,10 +278,8 @@ static void vfio_ap_unrealize(DeviceState *dev)
>
> static const Property vfio_ap_properties[] = {
> DEFINE_PROP_STRING("sysfsdev", VFIOAPDevice, vdev.sysfsdev),
> -#ifdef CONFIG_IOMMUFD
> DEFINE_PROP_LINK("iommufd", VFIOAPDevice, vdev.iommufd,
> TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
> -#endif
> };
>
> static void vfio_ap_reset(DeviceState *dev)
> @@ -320,21 +317,17 @@ static void vfio_ap_instance_init(Object *obj)
> vbasedev->mdev = true;
> }
>
> -#ifdef CONFIG_IOMMUFD
> static void vfio_ap_set_fd(Object *obj, const char *str, Error **errp)
> {
> vfio_device_set_fd(&VFIO_AP_DEVICE(obj)->vdev, str, errp);
> }
> -#endif
>
> static void vfio_ap_class_init(ObjectClass *klass, const void *data)
> {
> DeviceClass *dc = DEVICE_CLASS(klass);
>
> device_class_set_props(dc, vfio_ap_properties);
> -#ifdef CONFIG_IOMMUFD
> object_class_property_add_str(klass, "fd", NULL, vfio_ap_set_fd);
> -#endif
> dc->vmsd = &vfio_ap_vmstate;
> dc->desc = "VFIO-based AP device assignment";
> set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> @@ -347,11 +340,9 @@ static void vfio_ap_class_init(ObjectClass *klass, const void *data)
> object_class_property_set_description(klass, /* 3.1 */
> "sysfsdev",
> "Host sysfs path of assigned device");
> -#ifdef CONFIG_IOMMUFD
> object_class_property_set_description(klass, /* 9.0 */
> "iommufd",
> "Set host IOMMUFD backend device");
> -#endif
> }
>
> static const TypeInfo vfio_ap_info = {
> diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> index 2251facb356..c66f42a13c2 100644
> --- a/hw/vfio/ccw.c
> +++ b/hw/vfio/ccw.c
> @@ -15,7 +15,6 @@
> */
>
> #include "qemu/osdep.h"
> -#include CONFIG_DEVICES /* CONFIG_IOMMUFD */
> #include <linux/vfio.h>
> #include <linux/vfio_ccw.h>
> #include <sys/ioctl.h>
> @@ -647,10 +646,8 @@ static void vfio_ccw_unrealize(DeviceState *dev)
> static const Property vfio_ccw_properties[] = {
> DEFINE_PROP_STRING("sysfsdev", VFIOCCWDevice, vdev.sysfsdev),
> DEFINE_PROP_BOOL("force-orb-pfch", VFIOCCWDevice, force_orb_pfch, false),
> -#ifdef CONFIG_IOMMUFD
> DEFINE_PROP_LINK("iommufd", VFIOCCWDevice, vdev.iommufd,
> TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
> -#endif
> DEFINE_PROP_CCW_LOADPARM("loadparm", CcwDevice, loadparm),
> };
>
> @@ -679,12 +676,10 @@ static void vfio_ccw_instance_init(Object *obj)
> DEVICE(vcdev), true);
> }
>
> -#ifdef CONFIG_IOMMUFD
> static void vfio_ccw_set_fd(Object *obj, const char *str, Error **errp)
> {
> vfio_device_set_fd(&VFIO_CCW(obj)->vdev, str, errp);
> }
> -#endif
>
> static void vfio_ccw_class_init(ObjectClass *klass, const void *data)
> {
> @@ -692,9 +687,7 @@ static void vfio_ccw_class_init(ObjectClass *klass, const void *data)
> S390CCWDeviceClass *cdc = S390_CCW_DEVICE_CLASS(klass);
>
> device_class_set_props(dc, vfio_ccw_properties);
> -#ifdef CONFIG_IOMMUFD
> object_class_property_add_str(klass, "fd", NULL, vfio_ccw_set_fd);
> -#endif
> dc->vmsd = &vfio_ccw_vmstate;
> dc->desc = "VFIO-based subchannel assignment";
> set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> @@ -713,11 +706,9 @@ static void vfio_ccw_class_init(ObjectClass *klass, const void *data)
> object_class_property_set_description(klass, /* 3.0 */
> "force-orb-pfch",
> "Force unlimited prefetch");
> -#ifdef CONFIG_IOMMUFD
> object_class_property_set_description(klass, /* 9.0 */
> "iommufd",
> "Set host IOMMUFD backend device");
> -#endif
> object_class_property_set_description(klass, /* 9.2 */
> "loadparm",
> "Define which devices that can be used for booting");
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 94c174a773f..df617f1fe46 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -19,7 +19,6 @@
> */
>
> #include "qemu/osdep.h"
> -#include CONFIG_DEVICES /* CONFIG_IOMMUFD */
> #include <linux/vfio.h>
> #include <sys/ioctl.h>
>
> @@ -3471,9 +3470,7 @@ static void vfio_pci_realize(PCIDevice *pdev, Error **errp)
> ~vdev->host.slot || ~vdev->host.function)) {
> error_setg(errp, "No provided host device");
> error_append_hint(errp, "Use -device vfio-pci,host=DDDD:BB:DD.F "
> -#ifdef CONFIG_IOMMUFD
> "or -device vfio-pci,fd=DEVICE_FD "
> -#endif
> "or -device vfio-pci,sysfsdev=PATH_TO_DEVICE\n");
> return;
> }
> @@ -3816,22 +3813,18 @@ static const Property vfio_pci_properties[] = {
> qdev_prop_nv_gpudirect_clique, uint8_t),
> DEFINE_PROP_OFF_AUTO_PCIBAR("x-msix-relocation", VFIOPCIDevice, msix_relo,
> OFF_AUTO_PCIBAR_OFF),
> -#ifdef CONFIG_IOMMUFD
> DEFINE_PROP_LINK("iommufd", VFIOPCIDevice, vbasedev.iommufd,
> TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
> -#endif
> DEFINE_PROP_BOOL("skip-vsc-check", VFIOPCIDevice, skip_vsc_check, true),
> DEFINE_PROP_UINT16("x-vpasid-cap-offset", VFIOPCIDevice,
> vpasid_cap_offset, 0),
> };
>
> -#ifdef CONFIG_IOMMUFD
> static void vfio_pci_set_fd(Object *obj, const char *str, Error **errp)
> {
> VFIOPCIDevice *vdev = VFIO_PCI_DEVICE(obj);
> vfio_device_set_fd(&vdev->vbasedev, str, errp);
> }
> -#endif
>
> static void vfio_pci_class_init(ObjectClass *klass, const void *data)
> {
> @@ -3840,9 +3833,7 @@ static void vfio_pci_class_init(ObjectClass *klass, const void *data)
>
> device_class_set_legacy_reset(dc, vfio_pci_reset);
> device_class_set_props(dc, vfio_pci_properties);
> -#ifdef CONFIG_IOMMUFD
> object_class_property_add_str(klass, "fd", NULL, vfio_pci_set_fd);
> -#endif
> dc->vmsd = &vfio_cpr_pci_vmstate;
> dc->desc = "VFIO-based PCI device assignment";
> pdc->realize = vfio_pci_realize;
> @@ -3944,11 +3935,9 @@ static void vfio_pci_class_init(ObjectClass *klass, const void *data)
> "vf-token",
> "Specify UUID VF token. Required for VF when PF is owned "
> "by another VFIO driver");
> -#ifdef CONFIG_IOMMUFD
> object_class_property_set_description(klass, /* 9.0 */
> "iommufd",
> "Set host IOMMUFD backend device");
> -#endif
> object_class_property_set_description(klass, /* 9.1 */
> "x-device-dirty-page-tracking",
> "Disable device dirty page tracking and use "
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
>> 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
This should be
# ... -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0
qemu-system-*: -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0: Property 'vfio-pci.iommufd' not found
but, since we need to specify '-object iommufd,id=iommufd0' anyway,
the error is :
# ... -object iommufd,id=iommufd0 -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0
qemu-system-*: invalid object type: iommufd
and it stays the same with your proposal :
# ... -object iommufd,id=iommufd0 -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0
qemu-system-*: invalid object type: iommufd
> 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
> ```
This error only occurs when the kernel doesn't have proper IOMMUFD support.
I don't think it is worth mentioning for this change.
> 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.
yes. as said before, QEMU attaches to the device before connecting it
to the IOMMU backend. So the iommufd object is unused until we reach
this step of the device initialization.
> $ qemu-system-* -object iommufd,id=iommufd0
> can't create iommufd object: /dev/iommu not found
> Is your kernel config missing CONFIG_IOMMUFD?
Why not. Would you have time for it ?
> As well, we could report "Is your kernel config missing CONFIG_VFIO_DEVICE_CDEV?" on the error mentioned in commit message.
This could added in one of the error messages of iommufd_cdev_getfd().
> 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?".
The Kconfig file of the machines have 'imply IOMMUFD' so that the object
iommufd is only built on systems where it makes sense: i386, arm, s390x,
as of today. We should be fine.
Thanks,
C.
On 3/17/26 6:55 AM, Cédric Le Goater wrote: >> 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. > > yes. as said before, QEMU attaches to the device before connecting it > to the IOMMU backend. So the iommufd object is unused until we reach > this step of the device initialization. > >> $ qemu-system-* -object iommufd,id=iommufd0 >> can't create iommufd object: /dev/iommu not found >> Is your kernel config missing CONFIG_IOMMUFD? > > Why not. Would you have time for it ? > Sent a separate series here: https://lore.kernel.org/qemu-devel/20260317225751.1325098-1-pierrick.bouvier@linaro.org/T/#t Regards, Pierrick
On 3/17/26 6:55 AM, Cédric Le Goater wrote:
>>> 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
>
> This should be
>
> # ... -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0
> qemu-system-*: -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0: Property 'vfio-pci.iommufd' not found
>
> but, since we need to specify '-object iommufd,id=iommufd0' anyway,
> the error is :
>
> # ... -object iommufd,id=iommufd0 -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0
> qemu-system-*: invalid object type: iommufd
>
> and it stays the same with your proposal :
>
> # ... -object iommufd,id=iommufd0 -device vfio-pci,host=0000:01:00.0,iommufd=iommufd0
> qemu-system-*: invalid object type: iommufd
>
>
Right, in my previous answer, I was (wrongly) focused on kernel config
instead of QEMU one. I'll update message description.
>> 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
>> ```
>
> This error only occurs when the kernel doesn't have proper IOMMUFD support.
> I don't think it is worth mentioning for this change.
>
Ok, I'll remove it.
>
>> 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.
>
> yes. as said before, QEMU attaches to the device before connecting it
> to the IOMMU backend. So the iommufd object is unused until we reach
> this step of the device initialization.
>
>> $ qemu-system-* -object iommufd,id=iommufd0
>> can't create iommufd object: /dev/iommu not found
>> Is your kernel config missing CONFIG_IOMMUFD?
>
> Why not. Would you have time for it ?
>
Yes, I'll take a look to add it as an additional patch on top of this
series.
>> As well, we could report "Is your kernel config missing CONFIG_VFIO_DEVICE_CDEV?" on the error mentioned in commit message.
>
> This could added in one of the error messages of iommufd_cdev_getfd().
>
>> 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?".
>
> The Kconfig file of the machines have 'imply IOMMUFD' so that the object
> iommufd is only built on systems where it makes sense: i386, arm, s390x,
> as of today. We should be fine.
>
Good point, iommufd object won't be available in this case.
> Thanks,
>
> C.
>
>
Regards,
Pierrick
© 2016 - 2026 Red Hat, Inc.