Handle threshold register for guests
PATCH 1/1 Handle threshold register for guests
Hi!
The threshold register has been introduced in AMD RevF CPUs along with SVM (Actually this MCA/MCE msr register existed before, but had no meaning). Therefore no need for additional cpuid checks.
On read access it reports the HVM guest the register has been locked by the BIOS. This means, it is not available for OS use. Thus, write accesses are simply ignored.
This behaviour actually matches real HW, so guests can deal with this.
Further, this way no multiplexing for multiple guests is necessary. Please apply.
Signed off by: Christoph Egger <[email protected]>
Signature · 12 lines
AMD Saxony, Dresden Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
xen/arch/x86/hvm/svm/svm.c +16 -0
@@ -177,6 +177,14 @@ static inline int long_mode_do_msr_writeif ( !svm_paging_enabled (v) ) vmcb->efer &= ~(EFER_LME |EFER_LMA ); +break ; + +case MSR_K8_MC4_MISC :/* Threshold register */ +/* MCA/MCE: Threshold register is reported to be locked. +* So we ignore all write accesses. This behaviour +* matches real HW, so guests should have no problem +* with this. +*/ break ;default :
@@ -2062,6 +2070,14 @@ static inline void svm_do_msr_access( msr_content = v->arch.hvm_svm.cpu_shadow_efer;break ; +case MSR_K8_MC4_MISC :/* Threshold register */ +/* MCA/MCE: We report HVM guests, threshold register +* is not available for OS use. The value means, +* the msr has been locked by the BIOS. +*/ + msr_content =0x2000000000000000ULL ; +break ; +default :if (rdmsr_hypervisor_regs (ecx, &eax, &edx) ||rdmsr_safe (ecx, eax, edx) ==0 )
xen/include/asm-x86/msr.h +22 -0
@@ -216,6 +216,28 @@ static inline void write_efer(__u64 val)#define MSR_IA32_MC0_STATUS 0x401#define MSR_IA32_MC0_ADDR 0x402#define MSR_IA32_MC0_MISC 0x403 + +/* K8 MC MSR */ +#define MSR_K8_MC1_CTL 0x404 +#define MSR_K8_MC1_STATUS 0x405 +#define MSR_K8_MC1_ADDR 0x406 +#define MSR_K8_MC1_MISC 0x407 + +#define MSR_K8_MC2_CTL 0x408 +#define MSR_K8_MC2_STATUS 0x409 +#define MSR_K8_MC2_ADDR 0x40A +#define MSR_K8_MC2_MISC 0x40B + +#define MSR_K8_MC3_CTL 0x40C +#define MSR_K8_MC3_STATUS 0x40D +#define MSR_K8_MC3_ADDR 0x40E +#define MSR_K8_MC3_MISC 0x40F + +#define MSR_K8_MC4_CTL 0x410 +#define MSR_K8_MC4_STATUS 0x411 +#define MSR_K8_MC4_ADDR 0x412 +#define MSR_K8_MC4_MISC 0x413 +/* Pentium IV performance counter MSRs */ #define MSR_P4_BPU_PERFCTR0 0x300
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 11 lines · Christoph Egger
The threshold register has been introduced in AMD RevF CPUs along with SVM (Actually this MCA/MCE msr register existed before, but had no meaning). Therefore no need for additional cpuid checks.
On read access it reports the HVM guest the register has been locked by the BIOS. This means, it is not available for OS use. Thus, write accesses are simply ignored.
This behaviour actually matches real HW, so guests can deal with this.Further, this way no multiplexing for multiple guests is necessary. Please apply.
I can't find any information about the revised semantics of M4_MISC in the latest revision (3.12) of Volume 2 of the AMD64 Architecture Programmer's Manual. Am I looking in the wrong place?
Since we don't advertise SVM capability to guests, wouldn't they assume old semantics for this register anyway?
Thanks,
Keir
Quoted 36 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Keir Fraser
Sent: 24 May 2007 11:46
To: Egger, Christoph; [email protected]
Subject: Re: [Xen-devel] [PATCH] [HVM][SVM] Handle threshold register for guestsQuoted 1 line · Christoph Egger
The threshold register has been introduced in AMD RevF CPUs
along with SVM
Quoted 1 line
(Actually this MCA/MCE msr register existed before, but had
no meaning).
Quoted 3 lines
Therefore no need for additional cpuid checks.
On read access it reports the HVM guest the register has
been locked by the
Quoted 1 line
BIOS. This means, it is not available for OS use. Thus,
write accesses are
Quoted 2 lines
simply ignored.
This behaviour actually matches real HW, so guests can dealwith this.
Quoted 3 lines
Further, this way no multiplexing for multiple guests is necessary. Please apply.
I can't find any information about the revised semantics of
M4_MISCin the
latest revision (3.12) of Volume 2 of the AMD64 Architecture Programmer's
Manual. Am I looking in the wrong place?
Quoted 3 lines
Since we don't advertise SVM capability to guests, wouldn't they assume old
semantics for this register anyway?
Yes, you're looking in the wrong place the APM is for "generic functionality", the BIOS and Kernel Developer's Guide (BKDG) is more specific as to implementation details for the different generations, and on page 225 [public version], you'll find the details of this register.
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
32559.pdf
As to whether the processor expects this behaviour or not is a different question. But let's say they use the family/model CPUID info to identify if this feature is available or not, rather than the more loosely coupled feature-bit of SVM (e.g. a Sempron Rev F processor would have the functionality in this register, but no SVM bit set as it's not got SVM-feature).
I think the patch is OK to support any future OS that MAY try to use this register. It's not harming anything, right?
--
Mats
Quoted 12 lines
Thanks,
Keir_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 28 lines · Mats
Quoted 13 lines · Christoph Egger
Quoted 11 lines
The threshold register has been introduced in AMD RevF CPUs along with SVM (Actually this MCA/MCE msr register existed before, but had no meaning).
Therefore no need for additional cpuid checks.On read access it reports the HVM guest the register has been locked by the BIOS. This means, it is not available for OS use. Thus, write accesses are simply ignored.
This behaviour actually matches real HW, so guests can deal with this. Further, this way no multiplexing for multiple guests is necessary. Please apply.Quoted 6 lines
I can't find any information about the revised semantics of
M4_MISCin the latest revision (3.12) of Volume 2 of the AMD64 Architecture Programmer's Manual. Am I looking in the wrong place?Since we don't advertise SVM capability to guests, wouldn't they assume old semantics for this register anyway?
Yes, you're looking in the wrong place the APM is for "generic functionality", the BIOS and Kernel Developer's Guide (BKDG) is more specific as to implementation details for the different generations, and on page 225 [public version], you'll find the details of this register.
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
32559.pdf
Quoted 6 lines
As to whether the processor expects this behaviour or not is a different question. But let's say they use the family/model CPUID info to identify if this feature is available or not, rather than the more loosely coupled feature-bit of SVM (e.g. a Sempron Rev F processor would have the functionality in this register, but no SVM bit set as it's not got SVM-feature).
The code the patch adds will never run on these CPUs, so no problem.
Quoted 2 lines
I think the patch is OK to support any future OS that MAY try to use this register. It's not harming anything, right?
Yes, that's right.
<side node>
Linux/x86_64 does the threshold counting in software, but it reads the HW register at boot time one time for each CPU to get a value where to start counting from. With
my patch, Linux does not find the threshold register marked as not being available for OS use and starts counting from zero for sure.
</side node>
Signature · 12 lines
AMD Saxony, Dresden Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
Quoted 15 lines · Mats
Yes, you're looking in the wrong place the APM is for "generic functionality", the BIOS and Kernel Developer's Guide (BKDG) is more specific as to implementation details for the different generations, and on page 225 [public version], you'll find the details of this register.
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
32559.pdfAs to whether the processor expects this behaviour or not is a different question. But let's say they use the family/model CPUID info to identify if this feature is available or not, rather than the more loosely coupled feature-bit of SVM (e.g. a Sempron Rev F processor would have the functionality in this register, but no SVM bit set as it's not got SVM-feature).
Quoted 2 lines
I think the patch is OK to support any future OS that MAY try to use this register. It's not harming anything, right?
I'll take another look. I think the patch will be fine.
-- Keir