Am 01.03.2013 14:12, schrieb Jiri Denemark:
> On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
>> = Listing CPU models =
>> Requirement: libvirt needs to know which CPU models are available to be used
>> with the "-cpu" option.
>> Current problem: libvirt relies on help output parsing for that.

query-cpu-definitions is the QMP command to retrieve values compatible
with -cpu.

And if libvirt is not using it, I really don't understand why the work
of maintaining this crappy interface has been pushed onto us in the
first place? There is no reuse between -cpu ? and QMP implementations so
it's just extra work, there is no communicated or implemented way to
extend the arch_query_cpu_definitions() implementation to become more
usable for command line output implementation (e.g., associating a PVR
value with the model name for ppc) and, while we're at it, it uses
global functions plus a stub rather than a CPUState hook with a no-op
default implementation in qom/cpu.c...

>> Solution: use QMP qom-list-types command.
>>     Dependency: X86CPU subclasses.
>>     Limitation: needs a live QEMU process for the query.
> No problem, we already run QEMU and use several QMP commands to probe
> its capabilities. And "qom-list-types" is actually one of them. To get
> the list of CPU models, we would just call
>     {
>         "execute": "qom-list-types",
>         "arguments": {
>             "implements": "X86CPU"
>         }
>     }
> right?

Not quite, this would return abstract types as well, so you'd need to
add "abstract": "false" or so.
And you need to use the type name, not the struct name as argument, i.e.
"i386-cpu" or "x86_64-cpu". Note: This does not always match the
executable name since QOM names are supposed to be verbose (e.g., ppc64
vs. powerpc64-cpu) and some executables are misnamed (sh4 vs. superh-cpu).

For x86 today this will return one type, either "i386-cpu" or
"x86_64-cpu", that's why I have been pushing to implement model
subclasses. There's still some controversial discussions about how this
relates to KVM and TCG changing values of classes.

> What about other non-x86 architectures?

For some other architectures like arm this will return the full list of
available classes, but in "cortex-a9-arm-cpu" format, which is not
guaranteed to be compatible with -cpu but rather with -device where
already applicable.

> Will we need to use
> different class name or is there a generic CPU class that could be used
> universally?

"cpu" would currently work as well, but the CPU refactorings are
targetting to compile, e.g., arm-cpu and microblaze-cpu types into the
same executable, so "cpu" may lead to undesired results in the future
depending on what assumptions your code makes.


SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Reply via email to