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