Re: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Jiri Denemark <jdenemar(a)redhat.com> writes:
On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost(a)redhat.com> writes:
> > libvirt wants to know if the QEMU binary supports a given -cpu
> > option (normally CPU features that can be enabled/disabled using
> > "+foo"/"-foo").
>
> The obvious way to check whether a specific CPU supports it is to
> introspect that CPU.
>
> The obvious way to check whether all CPUs of interest support it
> (assuming that is a productive question) is to introspect all CPUs of
> interest. Works regardless of whether the option is inherited, which is
> really an implementation detail.
As Eduardo said, libvirt wants to know whether it can use a given CPU
feature with current QEMU binary. In -cpu help, we can see a list of
models and features QEMU understands, but we need to get similar info
via QMP. CPU models are easy, but how do we get the list of CPU
features? If introspection is the way to get it, I'm fine with that,
just beware that we don't actually know the name of the CPU object
(Westmere-x86_64-cpu), we only know the name of the CPU model
(Westmere).
Actually, you do:
{ "execute": "qom-list-types", "arguments": {
"implements": "cpu" } }
{"return": [{"name": "Westmere-x86_64-cpu"}, ...]}
So if the object name is needed, we need to query the
mapping from CPU model names to CPU object names.
Hmm. The problem is that some interfaces such as -cpu require a "CPU
model name", but introspection gives you the QOM type name. The mapping
from "model name" to type name even depends on the target: it's CPUClass
method class_by_name().
Can't say I like that, but we got to play the hand we were dealt, and
that means we need to provide a way to introspect the mapping between
CPU model name and QOM type name. Eduardo's plan to add the QOM type
name to query-cpu-definitions makes more sense to me now.