Re: KVM/QEMU Community call 29/04/2025 agenda items?

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il lun 28 apr 2025, 14:58 Philippe Mathieu-Daudé <philmd@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.liu@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.fsf@pond.sub.org>
    https://lore.kernel.org/qemu-devel/87a584b69n.fsf@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.