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