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.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list