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