On 3/13/26 12:50 AM, Cédric Le Goater wrote:
> On 3/12/26 23:44, Pierrick Bouvier wrote:
>> This series makes changes to hw/vfio to compile files only once.
>> Changes are pretty straightforward and are mostly extraction of kvm/other config
>> specific functions to proper files.
>> This is the last hw/* subsystem that needs to be changed for single-binary.
>>
>> Pierrick Bouvier (8):
>> hw/vfio/listener.c: remove CONFIG_KVM
>> hw/vfio/helpers.c: extract kvm helpers in kvm-helpers.c
>> hw/vfio/pci-quirks.c: remove CONFIG_VFIO_IGD
>> hw/vfio: eradicate CONFIG_IOMMU from sources
>> hw/vfio/pci.c: eradicate CONFIG_KVM
>> hw/vfio/ap.c: use full path for target specific header
>> hw/vfio/spapr.c: extract vfio_spapr_kvm_attach_tce to
>> hw/vfio/kvm-spapr.c
>> hw/vfio: all vfio files can now be common files
>>
>> hw/vfio/kvm-spapr.h | 12 +++
>> target/s390x/kvm/kvm_s390x.h | 2 +-
>> hw/vfio/ap.c | 11 +-
>> hw/vfio/ccw.c | 9 --
>> hw/vfio/helpers.c | 172 -------------------------------
>> hw/vfio/igd-stubs.c | 20 ++++
>> hw/vfio/kvm-helpers.c | 192 +++++++++++++++++++++++++++++++++++
>> hw/vfio/kvm-spapr.c | 47 +++++++++
>> hw/vfio/kvm-stubs.c | 35 +++++++
>> hw/vfio/listener.c | 4 -
>> hw/vfio/pci-quirks.c | 5 -
>> hw/vfio/pci.c | 37 +++----
>> hw/vfio/spapr.c | 30 +-----
>> hw/vfio/meson.build | 8 +-
>> 14 files changed, 331 insertions(+), 253 deletions(-)
>> create mode 100644 hw/vfio/kvm-spapr.h
>> create mode 100644 hw/vfio/igd-stubs.c
>> create mode 100644 hw/vfio/kvm-helpers.c
>> create mode 100644 hw/vfio/kvm-spapr.c
>> create mode 100644 hw/vfio/kvm-stubs.c
>>
>
> I am glad we are getting rid of #ifdef CONFIG in the code. I wonder
> why we stopped using stubs in the past.
>
Probably for convenience. An ifdef is quicker to add, can be more
readable, and the only downside is that it breaks all possibilities to
mix several targets in the same binary, which is a new and recent goal.
> Anyhow, as said, what bothers me with this change (which I like OTOH)
> is that it is exposing IOMMUFD support at the UAPI level. But,
>
> 1. only i386, s390x and arm have IOMMUFD support. Not PPC for instance.
> 2. downstream can compile support off
>
> That said, support should reach all platforms one day. So we could
> say that relying on a runtime check is preparing the future. I am
> not against the change but it needs more thinking on the consequences.
> IOW, a bit late for 11.0.
>
Sure, I'm posting it now but don't expect to get this merged for this
release.
The IOMMUFD part is indeed the one debatable in the series. My rationale
was that, even if it exposes iommufd properties, they won't have any
effect as long as kernel doesn't have support.
Having played with it in the past, and having discovered that arm64
kernel defconfig does not enable CONFIG_IOMMUFD, error message is quite
clear.
If you prefer, we could definitely try to build properties at runtime.
However, be aware that it's usually less readable (need to build a
dynamic array) and more clunky than the static const array, since it
requires a set_X callback instead of setting properties as a field. It's
usually our last solution resort if exposing things is not possible.
Let me know what you would prefer for it.
> The idea is great. Let's try for 11.1
>
> Thanks,
>
> C.
>
>
Thanks,
Pierrick