On 30/4/25 12:41, Markus Armbruster wrote:
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.
This this the single structure member conditional on field
selectable by ./configure (IOW, not host-dependent). I proposed
its removal in this patch:
https://lore.kernel.org/qemu-devel/20250429100419.20427-1-phi...@linaro.org/
IMHO conditionals should only depend on host / static configuration
features, not features modifiable from the command line. (I'm always
confused by KVM features published in the schema, but then you start
your binary with -accel=tcg and still can run KVM specific commands
via QMP, returning errors).
