aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/kvm
diff options
context:
space:
mode:
authorjohn cooper <john.cooper@redhat.com>2011-01-21 00:21:00 -0500
committerMarcelo Tosatti <mtosatti@redhat.com>2011-03-17 12:08:27 -0400
commit91c9c3eda4f3066980d13a6907ef84f3a99364bd (patch)
treeb39e69fd1fff6f86b0b29269c29f83ded11aa46f /arch/x86/kvm
parent3cba41307a2b1344ab8c1b9f55202d1e9d7bf81b (diff)
KVM: x86: handle guest access to BBL_CR_CTL3 MSR
A correction to Intel cpu model CPUID data (patch queued) caused winxp to BSOD when booted with a Penryn model. This was traced to the CPUID "model" field correction from 6 -> 23 (as is proper for a Penryn class of cpu). Only in this case does the problem surface. The cause for this failure is winxp accessing the BBL_CR_CTL3 MSR which is unsupported by current kvm, appears to be a legacy MSR not fully characterized yet existing in current silicon, and is apparently carried forward in MSR space to accommodate vintage code as here. It is not yet conclusive whether this MSR implements any of its legacy functionality or is just an ornamental dud for compatibility. While I found no silicon version specific documentation link to this MSR, a general description exists in Intel's developer's reference which agrees with the functional behavior of other bootloader/kernel code I've examined accessing BBL_CR_CTL3. Regrettably winxp appears to be setting bit #19 called out as "reserved" in the above document. So to minimally accommodate this MSR, kvm msr get will provide the equivalent mock data and kvm msr write will simply toss the guest passed data without interpretation. While this treatment of BBL_CR_CTL3 addresses the immediate problem, the approach may be modified pending clarification from Intel. Signed-off-by: john cooper <john.cooper@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Diffstat (limited to 'arch/x86/kvm')
-rw-r--r--arch/x86/kvm/x86.c19
1 files changed, 19 insertions, 0 deletions
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a7f65aa6eef6..7faf262ab202 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1592,6 +1592,12 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
1592 } else 1592 } else
1593 return set_msr_hyperv(vcpu, msr, data); 1593 return set_msr_hyperv(vcpu, msr, data);
1594 break; 1594 break;
1595 case MSR_IA32_BBL_CR_CTL3:
1596 /* Drop writes to this legacy MSR -- see rdmsr
1597 * counterpart for further detail.
1598 */
1599 pr_unimpl(vcpu, "ignored wrmsr: 0x%x data %llx\n", msr, data);
1600 break;
1595 default: 1601 default:
1596 if (msr && (msr == vcpu->kvm->arch.xen_hvm_config.msr)) 1602 if (msr && (msr == vcpu->kvm->arch.xen_hvm_config.msr))
1597 return xen_hvm_config(vcpu, data); 1603 return xen_hvm_config(vcpu, data);
@@ -1846,6 +1852,19 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
1846 } else 1852 } else
1847 return get_msr_hyperv(vcpu, msr, pdata); 1853 return get_msr_hyperv(vcpu, msr, pdata);
1848 break; 1854 break;
1855 case MSR_IA32_BBL_CR_CTL3:
1856 /* This legacy MSR exists but isn't fully documented in current
1857 * silicon. It is however accessed by winxp in very narrow
1858 * scenarios where it sets bit #19, itself documented as
1859 * a "reserved" bit. Best effort attempt to source coherent
1860 * read data here should the balance of the register be
1861 * interpreted by the guest:
1862 *
1863 * L2 cache control register 3: 64GB range, 256KB size,
1864 * enabled, latency 0x1, configured
1865 */
1866 data = 0xbe702111;
1867 break;
1849 default: 1868 default:
1850 if (!ignore_msrs) { 1869 if (!ignore_msrs) {
1851 pr_unimpl(vcpu, "unhandled rdmsr: 0x%x\n", msr); 1870 pr_unimpl(vcpu, "unhandled rdmsr: 0x%x\n", msr);