| Message ID | 1347979793-27045-2-git-send-email-Don@CloudSwitch.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? > c->ebx = signature[0]; > c->ecx = signature[1]; > c->edx = signature[2]; > -- > 1.7.1 >
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; c->ebx = signature[0]; c->ecx = signature[1]; c->edx = signature[2];