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>, "Ke, Liping" <liping.ke@xxxxxxxxx>
Subject: RE: [Xen-devel] mce_wrmsr() and (at least) HVM guests
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Wed, 23 Dec 2009 11:22:51 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 22 Dec 2009 19:23:18 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B30D17B02000078000272CF@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqDBw/TSeWxPIFGTpS8+s2C4RqZiwAbew8Q
Thread-topic: [Xen-devel] mce_wrmsr() and (at least) HVM guests
Jan, sorry for no response for this. It is not in my inbox, maybe is put into 
my junkmail box. (Really strange that some xen-devel mail will be put into 
junkmail, including my patch submission mail).

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.

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.

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?

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 .

I can cook patches for these issues, after I resolve the vMCE to pvops dom0, 
hopefully early next week.

--jyh


>-----Original Message-----
>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>Sent: Tuesday, December 22, 2009 9:03 PM
>To: Ke, Liping; Jiang, Yunhong
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] mce_wrmsr() and (at least) HVM guests
>
>>>> "Jan Beulich" <JBeulich@xxxxxxxxxx> 01.12.09 12:19 >>>
>>With mce_wrmsr() not permitting to write other than all zeroes or all ones
>>to MCG_CTL and MCn_CTL, it is not possible for guests to implement
>>workarounds (see the one in mce_cpu_quirks() which has been present in
>>Linux versions for a very long time). While one could expect PV guests to
>>be aware of that (and avoid the workaround), HVM guests clearly can't
>>be expected to. Thus the question is whether the handling should be
>>made a little more permissive.
>>
>>Initially I had thought of just making Xen check whether the bit(s) in
>>question are also off in the physical MSR, but that would imply that
>>Xen always has implemented at least all of the workarounds any guest
>>may know of. I'm not sure I have a good other idea, short of allowing
>>all writes to succeed.
>
>Ping?
>
>Jan


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

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