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

["Daniel P. Berrangé" <berrange@redhat.com>]

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