Jiri Denemark <jdenemar@redhat.com> writes:
On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote:
Eduardo Habkost <ehabkost@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.