On 09/18/12 11:05, Eduardo Habkost wrote:
On Tue, Sep 18, 2012 at 10:49:52AM -0400, Don Slutz wrote:
From http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/00100.html
EAX should be KVM_CPUID_FEATURES (0x40000001) not 0.
---
target-i386/kvm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 761a9b1..0c9f5dd 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -392,7 +392,7 @@ int kvm_arch_init_vcpu(CPUX86State *env)
c->function = KVM_CPUID_SIGNATURE;
if (env->cpuid_hv_level == 0) {
memcpy(signature, "KVMKVMKVM\0\0\0", 12);
- c->eax = 0;
+ c->eax = KVM_CPUID_FEATURES;
This makes the CPUID bits to suddenly change, when live-migrating to a
newer QEMU version.
Strictly speaking, this is never supposed to happen, but... on both
cases the meaning of the bits are the same (0 is documented as
equivalent to KVM_CPUID_FEATURES) and probably the guest will look at
them only once on boot. Do we really want to add migration-compatibility
code for this?
My vote would be no; because this should be ok and the tests that I know
of are all at boot time. I will look into adding
migration-compatibility. I also do not have any direct need for this
change, it just looked like the right thing to do.
c->ebx = signature[0];
c->ecx = signature[1];
c->edx = signature[2];
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
