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

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

[Alex Bennée]

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?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Philippe Mathieu-Daudé]

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

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

[Philippe Mathieu-Daudé]

On 28/4/25 14:57, Philippe Mathieu-Daudé wrote:
> 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).

FYI neither Markus nor Zhao can attend today's call, so not a good
time to discuss this topic.

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

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

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.

Paolo

>

[-- Attachment #2: Type: text/html, Size: 2206 bytes --]

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

[Alex Bennée]

Alex Bennée <alex.bennee@linaro.org> writes:

> Hi,
>
> The KVM/QEMU community call is at:
>
> https://meet.jit.si/kvmcallmeeting
> @
> 29/04/2025 14:00 UTC

Due to scheduling conflicts there will not be a call on the 13th of May
making the next call on the 27th.

>
> Are there any agenda items for the sync-up?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Markus Armbruster]

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.

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

[Daniel P. Berrangé]

On Wed, Apr 30, 2025 at 12:41:17PM +0200, Markus Armbruster wrote:
> 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.

snip

> 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.

NB, ...makes sense only when we have CONFIG_KVM **and** the QEMU
process was launched with '-accel kvm'.

It feels strange that we want our reported schema show a difference when
we launch "qemu-system-x86_64 -accel tcg" between two builds one with
and without CONFIG_KVM, when KVM is not in use ? 

Or to reverse the question, why does it matter if we report existence
of KvmPmuEventFormat unconditionally ?

> 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.

Is the precision we have justifiable ?

When it comes to runtime configuration QMP is already imprecise.

eg set-cpu-topology on x390 is KVM only but still there
   when running with TCG

eg reporting query-hotpluggable-cpus on machine types that
   lack hotplug

eg reporting set-numa-node on arches/machines that lack NUMA

eg reporting query-balloon when no balloon device is present

eg reporting various xen- commands when either the target
   or machine type lack Xen support

eg reporting many cxl-* commands when either the target
   or machine type lacks CXL support.

IOW the use of TARGET_ conditionals are only addressing a very
narrow area of (im)precision, whose rationale is largely an
artifact of our historical separate binary / multiple builds
choice. The only real justification for continuing with this
is that we've always done it.

Creating a general runtime conditional mechanism in QAPI feels
like opening a pandora's box.

We'll have a mechanism but it will be impractical to use it fully
enough to be able to claim we are actually precise. The scope of
runtime choices/conditions is too huge.

It risks creating a mechanism that requires a never ending stream
of patches to address continually reported gaps. A potentially
significant maintainer burden.

By comparison the CONFIG_ conditionals in QAPI, both the scope
and semantics clear and it is a fairly tractable problem, although
even there we miss them eg lack of CONFIG_XEN conditions on xen
commands.

> 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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Philippe Mathieu-Daudé]

On 30/4/25 12:41, Markus Armbruster wrote:
> 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.

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-philmd@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).

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

[Zhao Liu]

Ping Philippe?

> > 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.
> 
> NB, ...makes sense only when we have CONFIG_KVM **and** the QEMU
> process was launched with '-accel kvm'.
> 
> It feels strange that we want our reported schema show a difference when
> we launch "qemu-system-x86_64 -accel tcg" between two builds one with
> and without CONFIG_KVM, when KVM is not in use ? 
> 
> Or to reverse the question, why does it matter if we report existence
> of KvmPmuEventFormat unconditionally ?
> 
> > 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.
> 
> Is the precision we have justifiable ?
> 
> When it comes to runtime configuration QMP is already imprecise.
> 
> eg set-cpu-topology on x390 is KVM only but still there
>    when running with TCG
> 
> eg reporting query-hotpluggable-cpus on machine types that
>    lack hotplug
> 
> eg reporting set-numa-node on arches/machines that lack NUMA
> 
> eg reporting query-balloon when no balloon device is present
> 
> eg reporting various xen- commands when either the target
>    or machine type lack Xen support
> 
> eg reporting many cxl-* commands when either the target
>    or machine type lacks CXL support.

Indeed, I think Daniel's examples are great. @Philipppe, are these cases
considered in the context of single binary/heterogeneous emulation?

> IOW the use of TARGET_ conditionals are only addressing a very
> narrow area of (im)precision, whose rationale is largely an
> artifact of our historical separate binary / multiple builds
> choice. The only real justification for continuing with this
> is that we've always done it.
> 
> Creating a general runtime conditional mechanism in QAPI feels
> like opening a pandora's box.
> 
> We'll have a mechanism but it will be impractical to use it fully
> enough to be able to claim we are actually precise. The scope of
> runtime choices/conditions is too huge.
> 
> It risks creating a mechanism that requires a never ending stream
> of patches to address continually reported gaps. A potentially
> significant maintainer burden.
> 
> By comparison the CONFIG_ conditionals in QAPI, both the scope
> and semantics clear and it is a fairly tractable problem, although
> even there we miss them eg lack of CONFIG_XEN conditions on xen
> commands.
> 

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

[Philippe Mathieu-Daudé]

Hi Zhao,

On 7/5/25 10:24, Zhao Liu wrote:
> Ping Philippe?
> 
>>> 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.
>>
>> NB, ...makes sense only when we have CONFIG_KVM **and** the QEMU
>> process was launched with '-accel kvm'.
>>
>> It feels strange that we want our reported schema show a difference when
>> we launch "qemu-system-x86_64 -accel tcg" between two builds one with
>> and without CONFIG_KVM, when KVM is not in use ?
>>
>> Or to reverse the question, why does it matter if we report existence
>> of KvmPmuEventFormat unconditionally ?
>>
>>> 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.
>>
>> Is the precision we have justifiable ?
>>
>> When it comes to runtime configuration QMP is already imprecise.
>>
>> eg set-cpu-topology on x390 is KVM only but still there
>>     when running with TCG
>>
>> eg reporting query-hotpluggable-cpus on machine types that
>>     lack hotplug
>>
>> eg reporting set-numa-node on arches/machines that lack NUMA
>>
>> eg reporting query-balloon when no balloon device is present
>>
>> eg reporting various xen- commands when either the target
>>     or machine type lack Xen support
>>
>> eg reporting many cxl-* commands when either the target
>>     or machine type lacks CXL support.
> 
> Indeed, I think Daniel's examples are great. @Philipppe, are these cases
> considered in the context of single binary/heterogeneous emulation?

This is being actively discussed in this thread:
https://lore.kernel.org/qemu-devel/20250424183350.1798746-1-pierrick.bouvier@linaro.org/

> 
>> IOW the use of TARGET_ conditionals are only addressing a very
>> narrow area of (im)precision, whose rationale is largely an
>> artifact of our historical separate binary / multiple builds
>> choice. The only real justification for continuing with this
>> is that we've always done it.
>>
>> Creating a general runtime conditional mechanism in QAPI feels
>> like opening a pandora's box.
>>
>> We'll have a mechanism but it will be impractical to use it fully
>> enough to be able to claim we are actually precise. The scope of
>> runtime choices/conditions is too huge.
>>
>> It risks creating a mechanism that requires a never ending stream
>> of patches to address continually reported gaps. A potentially
>> significant maintainer burden.
>>
>> By comparison the CONFIG_ conditionals in QAPI, both the scope
>> and semantics clear and it is a fairly tractable problem, although
>> even there we miss them eg lack of CONFIG_XEN conditions on xen
>> commands.
>>

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

[Markus Armbruster]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 30/4/25 12:41, Markus Armbruster wrote:

[...]

>> 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.

[...]

> IMHO conditionals should only depend on host / static configuration
> features, not features modifiable from the command line.

This is how the QAPI schema works now.

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

Not exactly a ringing endorsement for keeping the QAPI schema work the
way it does now, isn't it?  ;)

The problem at hand is QAPI-generated files in a single binary.

Pierrick posted "[RFC PATCH 0/3] single-binary: make QAPI generated
files common".  The patches are flawed, but that's alright for RFC.

In review, I pointed out three possible solutions, and discussed their
pros and cons:

(1) Drop target-specific conditionals.

(2) Replace them by run-time checks.

(3) Have target-specific QAPI-generated code for multiple targets
    coexist in the single binary.

Both (1) and (3) keep the QAPI schema work as it does now.

Pierrick's patches are an incomplete attempt at (2).

Daniel made a case for (1).  You and I actually discussed (1) before,
and I encouraged you to explore it.

We can certainly discuss this some more, but I'd prefer to review a
working solution instead.

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

[Zhao Liu]

On Wed, May 07, 2025 at 05:11:39PM +0200, Markus Armbruster wrote:
> Date: Wed, 07 May 2025 17:11:39 +0200
> From: Markus Armbruster <armbru@redhat.com>
> Subject: Re: KVM/QEMU Community call 29/04/2025 agenda items?
> 
> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> 
> > On 30/4/25 12:41, Markus Armbruster wrote:
> 
> [...]
> 
> >> 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.
> 
> [...]
> 
> > IMHO conditionals should only depend on host / static configuration
> > features, not features modifiable from the command line.
> 
> This is how the QAPI schema works now.
> 
> >                                                          (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).
> 
> Not exactly a ringing endorsement for keeping the QAPI schema work the
> way it does now, isn't it?  ;)
> 
> The problem at hand is QAPI-generated files in a single binary.
> 
> Pierrick posted "[RFC PATCH 0/3] single-binary: make QAPI generated
> files common".  The patches are flawed, but that's alright for RFC.
> 
> In review, I pointed out three possible solutions, and discussed their
> pros and cons:
> 
> (1) Drop target-specific conditionals.
> 
> (2) Replace them by run-time checks.
> 
> (3) Have target-specific QAPI-generated code for multiple targets
>     coexist in the single binary.

Thank you Markus for your nice summary! I also apologize to you and
Philippe if I didn't understand correctly (I tried to look at
Pierrick's and Philippe's work, but still worry about I may have wrong
understanding :-) )

> Both (1) and (3) keep the QAPI schema work as it does now.
> 
> Pierrick's patches are an incomplete attempt at (2).

I see.

> Daniel made a case for (1).  You and I actually discussed (1) before,
> and I encouraged you to explore it.

And I notice Philippe has 2 patches:

(1) For QAPI, this is to drop target-specific cond:

https://lore.kernel.org/qemu-devel/20250429100419.20427-1-philmd@linaro.org/

I feel it's a smart way to make it optional.

(2) Not for QAPI, but this is try to add runtime check:

https://lore.kernel.org/qemu-devel/20250502214551.80401-5-philmd@linaro.org/

I am thinking about how kvm-pmu-filter could be aligned with these
current efforts in mail list.

I can drop all the target conditions for KvmPmuEventFormat:

    { 'enum': 'KvmPmuEventFormat',
      'data': ['raw', 'x86-select-umask', 'x86-masked-entry'] }

This is what you listed before and it is similar to the way in (1). But
only (1) is not enough because I can't make these formats as optional
(pls educate me if I'm wrong :-) ).

Therefore, I think I need run-time check like Philippe did in (2), in
my kvm-pmu.c file. Do you think so?

An additional question - about CONFIG_KVM - is that I see that it's all
currently focused on solving target-specific problems, and I understand
that it's not yet kvm-specific's turn.

But kvm-pmu-filter does (or, may :-) ) need CONFIG_KVM. My initial
thought is, is it possible to remove the CONFIG_KVM condition for
kvm-pmu-filter in QAPI and use the same runtime check? But this would
require accel-info as Philippe's work on target-info in [2]).

> We can certainly discuss this some more, but I'd prefer to review a
> working solution instead.

With so many options on the table, I'm a bit confused about the fate of
kvm-pmu-filter. Should this case wait for the most appropriate option to
come along, or could it move forward based on the status quo, and then
consider the refactoring later with the final optimal option?

Regards,
Zhao

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

[Markus Armbruster]

Zhao Liu <zhao1.liu@intel.com> writes:

> On Wed, May 07, 2025 at 05:11:39PM +0200, Markus Armbruster wrote:
>> Date: Wed, 07 May 2025 17:11:39 +0200
>> From: Markus Armbruster <armbru@redhat.com>
>> Subject: Re: KVM/QEMU Community call 29/04/2025 agenda items?
>> 
>> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
>> 
>> > On 30/4/25 12:41, Markus Armbruster wrote:
>> 
>> [...]
>> 
>> >> 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.
>> 
>> [...]
>> 
>> > IMHO conditionals should only depend on host / static configuration
>> > features, not features modifiable from the command line.
>> 
>> This is how the QAPI schema works now.
>> 
>> >                                                          (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).
>> 
>> Not exactly a ringing endorsement for keeping the QAPI schema work the
>> way it does now, isn't it?  ;)
>> 
>> The problem at hand is QAPI-generated files in a single binary.
>> 
>> Pierrick posted "[RFC PATCH 0/3] single-binary: make QAPI generated
>> files common".  The patches are flawed, but that's alright for RFC.
>> 
>> In review, I pointed out three possible solutions, and discussed their
>> pros and cons:
>> 
>> (1) Drop target-specific conditionals.
>> 
>> (2) Replace them by run-time checks.
>> 
>> (3) Have target-specific QAPI-generated code for multiple targets
>>     coexist in the single binary.
>
> Thank you Markus for your nice summary! I also apologize to you and
> Philippe if I didn't understand correctly (I tried to look at
> Pierrick's and Philippe's work, but still worry about I may have wrong
> understanding :-) )
>
>> Both (1) and (3) keep the QAPI schema work as it does now.
>> 
>> Pierrick's patches are an incomplete attempt at (2).
>
> I see.
>
>> Daniel made a case for (1).  You and I actually discussed (1) before,
>> and I encouraged you to explore it.
>
> And I notice Philippe has 2 patches:
>
> (1) For QAPI, this is to drop target-specific cond:
>
> https://lore.kernel.org/qemu-devel/20250429100419.20427-1-philmd@linaro.org/
>
> I feel it's a smart way to make it optional.
>
> (2) Not for QAPI, but this is try to add runtime check:
>
> https://lore.kernel.org/qemu-devel/20250502214551.80401-5-philmd@linaro.org/
>
> I am thinking about how kvm-pmu-filter could be aligned with these
> current efforts in mail list.
>
> I can drop all the target conditions for KvmPmuEventFormat:
>
>     { 'enum': 'KvmPmuEventFormat',
>       'data': ['raw', 'x86-select-umask', 'x86-masked-entry'] }

This is what you need to do if we pick solution (1).

> This is what you listed before and it is similar to the way in (1). But
> only (1) is not enough because I can't make these formats as optional
> (pls educate me if I'm wrong :-) ).
>
> Therefore, I think I need run-time check like Philippe did in (2), in
> my kvm-pmu.c file. Do you think so?

In general, not just for your KVM PMU filter work: dropping
target-specific conditionals makes the formerly conditional things exist
for targets where they didn't exist before.  This commonly breaks the
build for these targets.  To fix a target's build, we can either
implement things for the target, or make attempts to use them fail
cleanly.

> An additional question - about CONFIG_KVM - is that I see that it's all
> currently focused on solving target-specific problems, and I understand
> that it's not yet kvm-specific's turn.
>
> But kvm-pmu-filter does (or, may :-) ) need CONFIG_KVM. My initial
> thought is, is it possible to remove the CONFIG_KVM condition for
> kvm-pmu-filter in QAPI and use the same runtime check? But this would
> require accel-info as Philippe's work on target-info in [2]).

I'm afraid I don't understand your question.

>> We can certainly discuss this some more, but I'd prefer to review a
>> working solution instead.
>
> With so many options on the table, I'm a bit confused about the fate of
> kvm-pmu-filter. Should this case wait for the most appropriate option to
> come along, or could it move forward based on the status quo, and then
> consider the refactoring later with the final optimal option?

Up to you.

We'll hopefully reach consensus fairly soon.  You might want to wait a
few days for that.

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

[Daniel P. Berrangé]

On Wed, May 07, 2025 at 05:11:39PM +0200, Markus Armbruster wrote:
> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> 
> > On 30/4/25 12:41, Markus Armbruster wrote:
> 
> [...]
> 
> >> 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.
> 
> [...]
> 
> > IMHO conditionals should only depend on host / static configuration
> > features, not features modifiable from the command line.
> 
> This is how the QAPI schema works now.
> 
> >                                                          (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).
> 
> Not exactly a ringing endorsement for keeping the QAPI schema work the
> way it does now, isn't it?  ;)
> 
> The problem at hand is QAPI-generated files in a single binary.
> 
> Pierrick posted "[RFC PATCH 0/3] single-binary: make QAPI generated
> files common".  The patches are flawed, but that's alright for RFC.
> 
> In review, I pointed out three possible solutions, and discussed their
> pros and cons:
> 
> (1) Drop target-specific conditionals.
> 
> (2) Replace them by run-time checks.
> 
> (3) Have target-specific QAPI-generated code for multiple targets
>     coexist in the single binary.
> 
> Both (1) and (3) keep the QAPI schema work as it does now.
> 
> Pierrick's patches are an incomplete attempt at (2).
> 
> Daniel made a case for (1).  You and I actually discussed (1) before,
> and I encouraged you to explore it.
>
> We can certainly discuss this some more, but I'd prefer to review a
> working solution instead.

I've posted a minimal effort PoC for (1). It addresses the QAPI side of
the problem, but doesn't magically make "single binary" buildable as is.
It just removes QAPI from being a blocker for "single binary", and so
the remaining work is more of the boring refactoring to introduce virtual
methods on machines, so the QMP cmd impl behaviour  switches at runtime
based on what is configured & being run.

https://lists.nongnu.org/archive/html/qemu-devel/2025-05/msg01915.html

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|