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