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

[Zhao Liu <zhao1.liu@intel.com>]

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