(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@xxxxxxxxxx> 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@xxxxxxxxxx>
> > * 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@xxxxxxxxxxx>
> > * 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list