RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----Original Message-----
>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>Sent: Monday, January 04, 2010 4:09 PM
>To: Jiang, Yunhong
>Cc: Ke, Liping; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests
>
>>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 23.12.09 04:22 >>>
>>I think it is different for MCG_CTL and MCn_CTL:
>>For MCG_CTL, the SDM spec stated: "IA32_MCG_CTL controls the
>>reporting of machine-check exceptions. If present, writing 1s to this
>>register enables machine-check features and writing all 0s disables
>>machine-check features. All other values are undefined and/or
>>implementation specific.". So I assume current implementation is ok.
>
>I tend to disagree, based on the "and/or implementation specific": As
>long as model specific information is available to the kernel, it may
>validly write other values - as is happening for the specific AMD case.

Hmm, this make sense, originally I thought it's AMD specific.
>
>>For MCn_CTL, the spec only stated that "P6 family processors only
>>allow the writing of all 1s or all 0s to the IA32_MCi_CTL MSR". So
>>yes, current implementation is over-killed, especially I think we
>>should not care about P6 family in Xen environment.
>
>I agree here.
>
>>But the mce_cpu_quirks() give remind me if we should still split the
>>Intel/AMD MCE msr virtualization? For example, will AMD platform
>>allow IA32_MCE_CTL to be not all 1s and 0s?
>
>I don't think so, as per the above.

Agree.

>
>>And also another potential issue raised out. For example, guest has
>>clear one bit in MCn_CTL while physically it is enabled. If a error
>>corresponding to this bit really happen, at least we should not inject
>>a vMCE to guest. We will either kill the guest, or let the guest
>>continues, depends on the error type .
>
>Yes, this would make sense, albeit it seems overkill to me - there
>shouldn't really be disagreement in how specific models get handled.
>Instead, perhaps an unprivileged guest should be permitted to write
>zero bits wherever the underlying real register has them clear (as
>read back from hardware, not as written by Xen or dom0).

What do you mean of "write zero bits wherever the underlying real register has 
them clear"?
>
>>I can cook patches for these issues, after I resolve the vMCE to
>>pvops dom0, hopefully early next week.
>
>That would be great, thanks.

I'm working on this now.

--jyh

>
>Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel