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