On 7/20/2026 2:24 PM, Philippe Mathieu-Daudé wrote: > On 18/7/26 20:44, Pierrick Bouvier wrote: >> On 7/18/2026 4:51 AM, BALATON Zoltan wrote: >>> On Sat, 18 Jul 2026, Cédric Le Goater wrote: >>>> On 7/18/26 06:52, Pierrick Bouvier wrote: >>>>> On 7/17/2026 9:14 PM, Michael Tokarev wrote: >>>>>> On 7/17/26 22:40, Pierrick Bouvier wrote: >>>>>> >>>>>>> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/vfio/Kconfig? >>>>>>> ref_type=heads#L5 >>>>>>> >>>>>>> ``` >>>>>>> config VFIO >>>>>>> bool >>>>>>> depends on LINUX >>>>>>> ``` >>>>>>> >>>>>>> Incorrect, and it should exclude Linux hosts not supporting VFIO. >>>>>>> At least sparc64 to fix the current issue. >>>>>> >>>>>> Shouldn't there be "depends on LINUX & KVM" ? At least, this >>>>>> way we can do --disable-kvm and it will work. >>>>>> >>>>> >>>>> I think it's a safe choice, but not sure if we are supposed to be able >>>>> to use the exotic combination of vfio with tcg also. Maybe it doesn't >>>>> make any sense technically though, I don't know the arcane of vfio. >>>> >>>> VFIO works in some heterogeneous configurations, aarch64 TCG running >>>> on an x86 host for instance. The opposite doesn't. ppc64 TCG on an x86 >>>> used to work. The limitations primarily stem from architectural >>>> differences in the host/guest memory mode, CPU/IOMMU address spaces, >>>> assumptions, etc. >>>> >>>>> @Cédric, Any idea of which matrix of host/target is supposed to be >>>>> supported? > >>>> With KVM, the supported architectures are x86, aarch64, s390x, ppc64. > >>>> >>>> Overall, heterogeneous TCG configurations happen to work by accident. >>>> I would not consider them supported. >>> >>> VFIO (vfio-pci) works with PPC TCG and is used for passing through cards >>> including GPU to emulated AmigaNG machines (maybe also mac99). > > So also Kconfig PPC (32-bit). > > Can we assume the following is safe on 'LINUX && !KVM'? > > #include <linux/kvm.h> > >> Please do >>> not break that. There are some quirks mostly with GPUs, see https:// >>> qmiga.codeberg.page/qemu_vfio.html but it works and used by some people. >>> >> >> 👍 >> >> In this case, and we want to ensure we don't break any existing workflow >> we might now be aware of, a safe choice could be to restrict VFIO to all >> hosts that supports KVM. This is different from CONFIG_KVM, which is >> only enabled for new hosts. >> >> @Michael: You'll need to detect kvm hosts (see meson.build for >> kvm_targets), add a host config CONFIG_KVM_HOST, and use that for >> CONFIG_VFIO definition. This should restrict VFIO to host providing KVM, >> without limiting which target is ran. > > For the 11.1 release I'd go with this 1-line fix: > > - depends on LINUX > + depends on LINUX && (AARCH64 || I386 || PPC || S390X) >
It duplicates the information we have in meson.build from kvm_targets section. That's why I suggested to add a new CONFIG_KVM_HOST with this list directly from the same meson.build place. Not the end of the world though, but it's definitely not the thing you want to debug in a few years when soemone will ask "Why my device has KVM but no VFIO support"? >> >>> Regards, >>> BALATON Zoltan >> >> Regards, >> Pierrick >> >
