Re: [PATCH v5 8/8] hw/vfio: all vfio files can now be common files

["Alex Bennée" <alex.bennee@linaro.org>]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 8/19/2026 1:06 PM, Andreas Grapentin wrote:
>> On Aug 18 26, Pierrick Bouvier wrote:
>>> It would be better to keep it as system_ss, since bringing back
>>> specific_ss will break the single-binary compilation.
>>> It should not be needed to rely on target config within the C file
>>> directly. At least, we didn't meet any situation where it was.
>>> That said, there is nothing in CI (yet) that prevent such regression,
>>> but I would appreciate if you could keep it as it is for now.
>>>
>>> If you need to filter a specific function per config
>>> (host/target/whatever), the right way is to isolate this in a new file,
>>> and condition inclusion from build system instead.
>>>
>>> system_ss.add_all(when: 'CONFIG_X', if_true: [newfile.c])
>>> Also, you can add associated stubs for other configs in stub_ss.
>>> stub_ss.add(files('newfile-stubs.c'))
>>>
>>> I don't know the details of the series you sent (and too big for me to
>>> take a look now), but if you have a precise question on a specific
>>> patch, feel free to reach out to me by email.
>>>
>>> Regards,
>>> Pierrick
>> 
>> Thanks Patrick,
>> 
>> To give some context, the linked series enables s390 host linux KVM to
>> virtualize guests with different (non-native) guest architectures. So we
>> would need to build (on host architecture s390x):
>> 
>> a) qemu-system-s390x with vfio using asm-s390/kvm.h, and
>> b) qemu-system-aarch64 with vfio using asm-arm64/kvm.h
>> 
>> which (based on my current understanding of the code) would make it
>> necessary to build the kvm-helpers in the vfio code twice, once per
>> guest architecture s390x and aarch64.

These are common KVM API headers aren't they? Which bits do you need
apart from the ioctl #defines?

>>
>
> Depending which functions/constants you need from asm-$arch/kvm.h, the
> simpler is probably to expose it in a proper API, and then prefix
> symbols per architecture. Finally, you can have a dispatcher function to
> return the right value:
>
> void kvm_get_X() {
>   if (target_aarch64()) {
>     return kvm_aarch64_get_X();
>   }
>   else if (target_s390x()) {
>     return kvm_s390x_get_X();
>   }
>   g_assert_not_reached().
> }

This is basically KVMCPUOps (like TCGCPUOps) with extra steps. I suggest
that is the way to handle the abstraction of kvm_arch_* functions.

>
> However, it does not scale very well if you need to expose a lot of X.
> You could also generate a struct with all values populated per arch, and
> use that.
>
> What kind of information do you need to extract from this header?
>
>> I understand that this is a problem for the single-binary efforts of
>> qemu, and needs further thought. We are currently trying to come up with
>> an approach that more closely aligns with the single-binary goal, and
>> any advice you could give to that end would be appreciated :)
>> 
>> Of course this problem extends to all components in qemu that require
>> architecture-specific components of the KVM UAPI.
>>
>
> We didn't really meet any issue so far with this, but maybe it's because
> we didn't yet to mix two different arch supporting kvm. In all cases, we
> take the problems one after another, and we don't anticipate things - it
> proved to an inefficient approach.
>
>> Thanks,
>> Andreas
>
> Regards,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro