(CCing Luiz, in case he can give some advice about the expectations of QMP semantics stability) On Fri, Jan 31, 2014 at 03:48:53PM +0100, Igor Mammedov wrote:
On Thu, 30 Jan 2014 17:48:52 -0200 Eduardo Habkost <ehabkost@redhat.com> wrote:
Is there any hope to get this into QEMU 2.0, or it is now too late? I got almost no feedback on take 6 (submitted November 27).
This is the main blocker to allow libvirt finally implement an equivalent to the "enforce" flag, finally making the CPU configuration safe and sane (today libvirt simply ignores GET_SUPPORTED_CPUID information, and features are silently disabled because "enforce" is not used).
This blocks libvirt because the current available interfaces requires re-running QEMU for each CPU model to be probed. Having the x86 CPU subclasses allow libvirt to simply create and destroy CPU objects from each available CPU class, and query for the results using QMP.
Demonstration of how this can be used, below:
Running QEMU as: $ qemu-system-x86_64 -enable-kvm -machine none -monitor stdio -qmp unix:/tmp/qmp,server,nowait -nographic
Then running qmp-shell as: $ ./scripts/qmp/qmp-shell /tmp/qmp [...] (QEMU) object-add qom-type=host-x86_64-cpu id=probing-host-cpu-type [...] (QEMU) qom-list path=/objects/ that's abusing of object-add interface and due to recent changes, object-add won't accept arbitrary objects.
see "[PATCH v1 3/4] add optional 2nd stage initialization to -object/object-add commands"
libvirt probably could use device_add instead to the same effect.
I don't mind which command is used, as long as we have the same effect. I used object-add in my example because device_add rejects the CPU classes by now (because they have cannot_instantiate_with_device_add_yet=true). But now I have one question: how can people know which parts of the QMP semantics will be stable, and which parts are subject to change?
BTW how libvirt would discover values for qom-type=foo?
I don't know, but I assume there's an appropriate command to list qdev and/or QOM classes, already? In the worst case, libvirt can already use the query-cpu-definitions command. But in this case, libvirt would have to encode the assumption that the CPU class names will be "<model>-<arch>-cpu". Or we could provide a new property on the query-cpu-definitions output containing the class name (that sounds appropriate, considering that the "-cpu" option doesn't get a class name (yet?)). The specifics are not set in stone, and I expect other developers to help me guide the libvirt developers and give them recommendations on how to query for the needed information (because there are multiple ways to do the same thing in QMP, as far as I can see).
{u'return': [{u'type': u'child<Haswell-x86_64-cpu>', u'name': u'probing-cpu-type-Haswell'}, {u'type': u'child<Westmere-x86_64-cpu>', u'name': u'probing-cpu-type-Westmere'}, {u'type': u'child<Nehalem-x86_64-cpu>', u'name': u'probing-cpu-type-Nehalem'}, {u'type': u'child<host-x86_64-cpu>', u'name': u'probing-host-cpu-type'}, {u'type': u'string', u'name': u'type'}]} (QEMU) qom-list path=/objects/probing-cpu-type-Haswell/ {u'return': [{u'type': u'X86CPUFeatureWordInfo', u'name': u'filtered-features'}, {u'type': u'X86CPUFeatureWordInfo', u'name': u'feature-words'}, {u'type': u'int', u'name': u'apic-id'}, {u'type': u'int', u'name': u'tsc-frequency'}, {u'type': u'string', u'name': u'model-id'}, {u'type': u'string', u'name': u'vendor'}, {u'type': u'int', u'name': u'xlevel'}, {u'type': u'int', u'name': u'level'}, {u'type': u'int', u'name': u'stepping'}, {u'type': u'int', u'name': u'model'}, {u'type': u'int', u'name': u'family'}, {u'type': u'link<bus>', u'name': u'parent_bus'}, {u'type': u'boolean', u'name': u'enforce'}, {u'type': u'boolean', u'name': u'check'}, {u'type': u'boolean', u'name': u'hv-time'}, {u'type': u'boolean', u'name': u'hv-vapic'}, {u'type': u'boolean', u'name': u'hv-relaxed'}, {u'type': u'int', u'name': u'hv-spinlocks'}, {u'type': u'boolean', u'name': u'pmu'}, {u'type': u'bool', u'name': u'realized'}, {u'type': u'string', u'name': u'type'}]} (QEMU) qom-get path=/objects/probing-cpu-type-Haswell property=feature-words {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658, u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax': 1073741825, u'features': 16777339}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 3221225473, u'features': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 2147483649, u'features': 1}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483649, u'features': 672139264}, {u'cpuid-register': u'EBX', u'cpuid-input-eax': 7, u'features': 4025, u'cpuid-input-ecx': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 1, u'features': 2549756419}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 1, u'features': 126614525}]} (QEMU) qom-get path=/objects/probing-cpu-type-Haswell property=filtered-features {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658, u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax': 1073741825, u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 3221225473, u'features': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 2147483649, u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483649, u'features': 0}, {u'cpuid-register': u'EBX', u'cpuid-input-eax': 7, u'features': 0, u'cpuid-input-ecx': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 1, u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 1, u'features': 0}]} (QEMU) qom-get path=/objects/probing-host-cpu-type property=feature-words {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658, u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax': 1073741825, u'features': 16777467}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 3221225473, u'features': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 2147483649, u'features': 1}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483649, u'features': 697564159}, {u'cpuid-register': u'EBX', u'cpuid-input-eax': 7, u'features': 2, u'cpuid-input-ecx': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 1, u'features': 2193236483}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 1, u'features': 260832255}]} (QEMU) qom-get path=/objects/probing-host-cpu-type property=filtered-features {u'return': [{u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483658, u'features': 0}, {u'cpuid-register': u'EAX', u'cpuid-input-eax': 1073741825, u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 3221225473, u'features': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 2147483649, u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 2147483649, u'features': 0}, {u'cpuid-register': u'EBX', u'cpuid-input-eax': 7, u'features': 0, u'cpuid-input-ecx': 0}, {u'cpuid-register': u'ECX', u'cpuid-input-eax': 1, u'features': 0}, {u'cpuid-register': u'EDX', u'cpuid-input-eax': 1, u'features': 0}]}
Changes from take 6:
* Rebase against uq/master * Patch 1/7: * Check for __i386__ on host_cpuid() so the code compiles properly on non-x86 hosts. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> * Don't add assert(kvm_enabled()) line, which is not necessary to help the compiler (and wouldn't help it if using -DNDEBUG, anyway). Reported-by: Richard Henderson <rth@twiddle.net> * Commit message update
Eduardo Habkost (7): target-i386: Eliminate CONFIG_KVM #ifdefs target-i386: Don't change x86_def_t struct on cpu_x86_register() target-i386: Move KVM default-vendor hack to instance_init target-i386: Rename cpu_x86_register() to x86_cpu_load_def() target-i386: Call x86_cpu_load_def() earlier target-i386: Rename x86_def_t to X86CPUDefinition target-i386: CPU model subclasses
target-i386/cpu-qom.h | 13 ++ target-i386/cpu.c | 402 ++++++++++++++++++++++++++++++-------------------- target-i386/cpu.h | 2 - 3 files changed, 256 insertions(+), 161 deletions(-)
-- 1.8.4.2
-- Regards, Igor
-- Eduardo