Re: [libvirt] [Qemu-devel] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU
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.
Regards,
Andreas
But there's something important in this case: the resulting CPUID
data
for a specific machine-type + CPU-model combination must be always the
same, forever. This means libvirt may even use a static table, or cache
this information indefinitely.
(Note that I am not talking about "-cpu host", here, but about all the
other CPU models)
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg