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.
>
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().
}
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
