Jiri Denemark <jdenemar@xxxxxxxxxx> writes:
> On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@xxxxxxxxxx> 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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list