WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Mon, 4 Jan 2010 16:31:51 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Ke, Liping" <liping.ke@xxxxxxxxx>
Delivery-date: Mon, 04 Jan 2010 00:33:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B41B03F020000780002809D@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B1509BD0200007800022D3B@xxxxxxxxxxxxxxxxxx> <4B30D17B02000078000272CF@xxxxxxxxxxxxxxxxxx> <C8EDE645B81E5141A8C6B2F73FD9265107A292FC7E@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B41B03F020000780002809D@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqNFSrmfwyDHzXLSpGiFGddUiiHVQAAmcLw
Thread-topic: [Xen-devel] mce_wrmsr() and (at least) HVM guests
>-----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

<Prev in Thread] Current Thread [Next in Thread>