[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> 
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:
Higher 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.