Paolo Bonzini <pbonz...@redhat.com> writes:
> Il lun 28 apr 2025, 14:58 Philippe Mathieu-Daudé <phi...@linaro.org> ha
> scritto:
>
>> On 28/4/25 13:05, Alex Bennée wrote:
>> >
>> > Hi,
>> >
>> > The KVM/QEMU community call is at:
>> >
>> > https://meet.jit.si/kvmcallmeeting
>> > @
>> > 29/04/2025 14:00 UTC
>> >
>> > Are there any agenda items for the sync-up?
>> >
>>
>> For single binary / heterogeneous emulation, we'd like QAPI to
>> be "feature-agnostic". In particular, using the example of KVM
>> accelerator, whether a binary can run with it built-in or not
>> should be is irrelevant for management applications: they should
>> only check if it is used (enabled).
>>
>> The following series is adding KVM specific structures and commands:
>>
>> https://lore.kernel.org/qemu-devel/20250409082649.14733-2-zhao1....@intel.com/
>> It could be interesting to discuss if this can be avoided. But this
>> can also be discussed on the mailing list (as it is still currently).
>>
>
> Would it be possible to just mark the commands as "do not autoregister" and
> then do the registration (for example) at machine/accelerator/CPU creation?
>
> I think qemu-ga already has a similar run-time registration model but I
> don't know why QEMU does not use it.
I think we covered this to a degree in
Subject: Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common
Message-ID: <87a584b69n....@pond.sub.org>
https://lore.kernel.org/qemu-devel/87a584b69n....@pond.sub.org/
But let me try to give you a shorter argument.
Pierrick's stated goal is to have no noticable differences between the
single binary and the qemu-system-<target> it covers.
We have two external interfaces to worry about: QMP and the command
line. Let's ignore the latter for now.
Target-specific differences in *syntax* come from QAPI schema
conditionals with target-specific conditions. Example:
{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'],
'if': { 'any': [ 'TARGET_PPC',
'TARGET_ARM',
'TARGET_I386',
'TARGET_S390X',
'TARGET_MIPS',
'TARGET_LOONGARCH64',
'TARGET_RISCV' ] } }
This command is only defined for some targets.
The value of query-qmp-schema reflects this: it has
query-cpu-definitions exactly when the condition is satisfied. The
condition is evaluated at compile-time, because that's how QAPI schema
'if' works.
Say we drop the condition and instead add an equivalent run-time
condition to command registration. This preserves behavior of command
execution. But query-qmp-schema now has query-cpu-definitions *always*.
This is a noticable difference. It may break management applications
that use query-qmp-schema to probe for the command.
Moreover, conditionals aren't limited to commands. Example:
{ 'struct': 'CpuModelExpansionInfo',
'data': { 'model': 'CpuModelInfo',
'deprecated-props' : { 'type': ['str'],
---> 'if': 'TARGET_S390X' } },
'if': { 'any': [ 'TARGET_S390X',
'TARGET_I386',
'TARGET_ARM',
'TARGET_LOONGARCH64',
'TARGET_RISCV' ] } }
Here we have a conditional member.
Another example: the KVM PMU filter series linked above wants to define
{ 'enum': 'KvmPmuEventFormat',
'data': ['raw', 'x86-select-umask', 'x86-masked-entry'] }
The enum makes sense only when we have CONFIG_KVM. Member @raw makes
sense regardless of target then. The other two only for TARGET_I386.
We could elect to forgo such conditionals. The main disadvantage is
loss of precision in query-qmp-schema. Which may or may not matter, and
may or may not box us into corners.
Pierrick volunteered to explore evaluating target-specific QAPI-Schem
conditionals at run-time instead of compile-time. This would preserve
the value of query-qmp-schema, unlike conditional command registration.
Finally, syntax isn't everything. We need to preserve behavior, too.
But that's a separate topic.
