Re: [Qemu-devel] [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU

[Eduardo Habkost]

On Thu, Jul 25, 2013 at 11:14:16AM +0200, Andreas Färber wrote:
> Am 24.07.2013 20:25, schrieb Eduardo Habkost:
> > In addition to the "-cpu host" KVM initialization problem, this is an
> > additional problem with the current interfaces provided by QEMU:
> > 
> > 1) libvirt needs to query data that depend on chosen machine-type and
> >    CPU model
> > 2) Some machine-type behavior is code and not introspectable data
> >    * Luckily most of the data we need in this case should/will be
> >      encoded in the compat_props tables.
> >    * In either case, we don't have an API to query for machine-type
> >      compat_props information yet.
> 
> ... and I don't think we should add such a thing. It is an internal
> implementation detail, whose results should be inspected instead.
> 
> > 3) CPU model behavior will be modelled as CPU class behavior. Like
> >    on the machine-type case, some of the CPU-model-specific behavior may
> >    be modelled as code, and not introspectable data.
> >    * However, e may be able to eventually encode most or all of
> >      CPU-model-specific behavior simply as different per-CPU-class
> >      property defaults.
> >    * In either case, we don't have an API for QOM class introspection,
> >      yet.
> 
> If I understood Anthony correctly on the previous call then that is by
> design. We have a query-cpu-definitions QMP API to obtain CPU models
> though. And qom-list-types to discover QOM types. The CPU can then be
> instantiated via -cpu (the type via -device/-object on other targets),
> inspected with qom-list/qom-get API and modified with qom-set.
> 
> The problem with the latter is that devices/CPUs get realized in code
> rather than shortly before emulation/virtualization starts - that's what
> my recursive QOM realization series prepared to address, but Paolo
> veto'ed that and hasn't provided sufficient feedback on what exactly his
> concerns are founded on and what he proposes instead. In particular:
> Would walking the qdev bus tree instead of the QOM composition tree
> address the concerns?
> 
> Depending on what libvirt is actually trying to do, the above combined
> with Igor's feature properties and -S might do the job. For x86 the CPUs
> are easily locatable in the QOM tree via ICC.

I still don't see how the above would solve the bigger problem: libvirt
needs a way to find out how exactly "-machine foo-1.0 -cpu bar" looks
different from "-machine foo-1.1 -cpu bar", but don't want to execute
QEMU multiple times just to find that out.

-- 
Eduardo