On 17.05.2009, at 11:54, Avi Kivity <avi@xxxxxxxxxx> wrote:
Alexander Graf wrote:
Hyper-V uses some MSRs, some of which are actually reserved for
BIOS usage.
But let's be nice today and have it its way, because otherwise it
fails
terribly.
For MSRs where I could find a name I used the name, otherwise
they're just
added in their hex form for now.
Most of these are not Hyper-V MSRs. They are x86 MSRs that happen
to be hit by Hyper-v.
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index ef43a18..30e6b43 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1932,6 +1932,7 @@ static int svm_get_msr(struct kvm_vcpu *vcpu,
unsigned ecx, u64 *data)
*data = svm->hsave_msr;
break;
case MSR_VM_CR:
+ case 0x40000081:
*data = 0;
break;
This probably is a Hyper-V MSR, but I don't see how it expects it to
be present in real hardware. Are you sure this is really needed?
Well hyper-v just crashes/reboots if it get a #gp on that msr, so I
suppose yes.
@@ -2034,6 +2035,10 @@ static int svm_set_msr(struct kvm_vcpu
*vcpu, unsigned ecx, u64 data)
case MSR_VM_HSAVE_PA:
svm->hsave_msr = data;
break;
+ case MSR_VM_CR:
+ case MSR_VM_IGNNE:
+ case MSR_K8_HWCR:
+ break;
Please add a ratelimited printk() if any value is written which
would cause behaviour which we do not emulate. This will prevent a
guest getting unexpected behaviour silently.
Right. Good catch.
Alex
--
error compiling committee.c: too many arguments to function
--
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