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] [Patch 0/3]RAS(Part II)--Intel MCA enalbing in XEN

To: "Ke, Liping" <liping.ke@xxxxxxxxx>
Subject: Re: [Xen-devel] [Patch 0/3]RAS(Part II)--Intel MCA enalbing in XEN
From: Frank van der Linden <Frank.Vanderlinden@xxxxxxx>
Date: Fri, 20 Mar 2009 17:46:19 -0600
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 20 Mar 2009 16:46:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E2263E4A5B2284449EEBD0AAB751098401CE2D1149@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <E2263E4A5B2284449EEBD0AAB751098401CE2D1149@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.17 (X11/20081023)
Ke, Liping wrote:

The patches are for MCA enabling in XEN. Those patches based on AMD and SUN's 
MCA related jobs.
We have some discussions with AMD/SUN and did refinements from the last sending. Also we rebase it after SUN's latest improvements. We will have following patches for recovery actions. This is a basic framework for Intel MCA.

I looked the patches over a little more closely, and merged them with my -unstable tree. I found a few minor issues:

* some compile issues with printk format strings in the case of DEBUG and 32bit * in severity_scan, use mca_rdmsrl and mca_wrmsrl to work correctly for simulated errors using injection * in severity_scan, if the MSR values were injected for debugging purposes, don't panic but keep going, since the injected values will be lost at reboot, and this is just a simulated #MC anyway, there is no danger of losing state

I'll attach a little patch to fix these issues. I haven't tested this patch yet, although the compile fixes have been "tested".

Finally, one final question:

2) When MCE# happens, all CPUs enter MCA context. The first CPU who read&clear 
the error MSR bank will be this
    MCE# owner. Necessary locks/synchronization will help to judge the owner 
and select most severe error.

Is it always true (at least, for Intel CPUs of family 6 and 15) that when a #MC happens, *all* CPUs will receive a #MC trap? I couldn't find this anywhere in the documentation.

If this is true, I'll change the MCE injection code to simulate #MC on all CPUs in the case of an Intel system.

- Frank

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

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