[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2 V2] hvm, svm: Update AMD Thresholding MSR definitions
On 1/28/2014 5:17 AM, Jan Beulich wrote: On 27.01.14 at 23:44, Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx> wrote:MSR 0xC000040A is marked as reserved from Fam15 onwards and MSR 0x413 is marked alias of MSR0xC000040A on Fam10 BKDG. So remove the unnecessary definition of the reserved MSR and use MSR_IA32_MCx_MISC() to define MSR 0x413.My Fam10 BKDG version doesn't say anything like this. Instead it says that the low 32 bits of all 4 registers are identical (i.e. all are aliasing 0x413), whereas the high 32 bits are different among all the four registers (with 0xc000040a having them all zero). Thanks for pointing this out; looks like MSR 0xc000040a is zeroed out completely: (F3x178 (MSRC000_040A): RAZ.)(page 339 on http://support.amd.com/TechDocs/31116.pdf) I have reworded commit message which (hopefully) conveys this better.. Also, according to BKDG, MSR 0x413 is the first of the thresholding registers; MSR 0xC0000408 and MSR 0xC0000409 are second and third respectively. So rework the #define's accordingly. Fam15 Model 00h-0fh BKDG reference: http://support.amd.com/TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdfHigher model numbers appear to also have 0xc0000409 reserved... Yes, thanks again for the pointer..I have now reworked the code to care for the existence of extended block of MC4_MISC registers.. (Note: 0xc0000409 is reserved in newer model of F15h, while both 0xc0000408 and 0xc0000409 are reserved in F16h) a) If the registers exist in HW, then we continue to enforce current policy of not emulating as we do not expose MC4 to guest b) If they don't, then #GP fault to guest. -Aravind. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |