[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties
Date: Fri, 11 Nov 2016 15:29:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Jiri Denemark <address@hidden> writes:

> On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
>> Eduardo Habkost <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]