Xen devel - Dec 2011 - [PATCH] X86 MCE: Add more strict sanity check of one SRAR case

Jan,

I cannot access my remote office desktop today (network maintain), so cannot
reply the SRAR patch email we discussed last month.

At the last email we basically agree that the SRAR patch itself looks fine, only
with 1 concern about ''guest_mode'' (in fact the SRAR patch
itself didn''t involved guest_mode), and the SRAR patch not in xen
unstable tree yet.
Currently I still don''t find out an alternative way to solve the
guest_mode issue, so in order to be safe I add this patch.
I think although it may be some overkilled, it''s OK to keep it safe
here, after all the SRAR case which RIPV = EIPV = 0 occur rarely.

Thanks,
Jinsong

=====================================
X86 MCE: Add more strict sanity check of one SRAR case

When RIPV = EIPV = 0, it''s a little bit tricky. It may be an
asynchronic error, currently we have no way to precisely locate whether the
error occur at guest or hypervisor.
To avoid handling error in wrong way, we treat it as unrecovered.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

# HG changeset patch
# Parent e758b1d928e3d663602741ddc7f55461e2187829

diff -r e758b1d928e3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c       Sun Oct 30 17:50:53 2011 -0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c       Fri Dec 02 15:16:52 2011 -0800
@@ -367,8 +367,18 @@
         return 0;

     gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-    /* Xen is not pre-emptible */
-    if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
+
+    /*
+     * FIXME: When RIPV = EIPV = 0, it''s a little bit tricky. It may
be an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV = 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+        (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
         return -1;

     return mce_action(regs, mctc) == MCER_RESET ? -1 : 0;



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

Jan,

Attached is the email we discuss last month, and 2 mce patches:
srar-1.patch is the patch we discussed before,
srar-guest-mode.patch is an additional patch w/ more strict sanity checkof RIPV
= EIPV = 0.
Any comments please let me know.

Thanks,
Jinsong

________________________________

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Liu, Jinsong
Sent: Friday, December 02, 2011 11:55 PM
To: jbeulich@suse.com
Cc: keir.xen@gmail.com; xen-devel@lists.xensource.com; Jiang, Yunhong
Subject: [Xen-devel] [PATCH] X86 MCE: Add more strict sanity check of one SRAR
case


Jan,
 
I cannot access my remote office desktop today (network maintain), so cannot
reply the SRAR patch email we discussed last month.
 
At the last email we basically agree that the SRAR patch itself looks fine, only
with 1 concern about ''guest_mode'' (in fact the SRAR patch
itself didn''t involved guest_mode), and the SRAR patch not in xen
unstable tree yet.
Currently I still don''t find out an alternative way to solve the
guest_mode issue, so in order to be safe I add this patch.
I think although it may be some overkilled, it''s OK to keep it safe
here, after all the SRAR case which RIPV = EIPV = 0 occur rarely.
 
Thanks,
Jinsong
 
===================================== 
X86 MCE: Add more strict sanity check of one SRAR case
 
When RIPV = EIPV = 0, it''s a little bit tricky. It may be an
asynchronic error, currently we have no way to precisely locate whether the
error occur at guest or hypervisor.
To avoid handling error in wrong way, we treat it as unrecovered.
 
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
 
# HG changeset patch
# Parent e758b1d928e3d663602741ddc7f55461e2187829
 
diff -r e758b1d928e3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c       Sun Oct 30 17:50:53 2011 -0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c       Fri Dec 02 15:16:52 2011 -0800
@@ -367,8 +367,18 @@
         return 0;
 
     gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-    /* Xen is not pre-emptible */
-    if ( !(gstatus & MCG_STATUS_RIPV) && !guest_mode(regs))
+
+    /*
+     * FIXME: When RIPV = EIPV = 0, it''s a little bit tricky. It may
be an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV = 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+        (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
         return -1;
 
     return mce_action(regs, mctc) == MCER_RESET ? -1 : 0;




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

>>> On 05.12.11 at 14:09, "Liu, Jinsong"
<jinsong.liu@intel.com> wrote:
> Attached is the email we discuss last month, and 2 mce patches:
> srar-1.patch is the patch we discussed before,
> srar-guest-mode.patch is an additional patch w/ more strict sanity checkof 
> RIPV = EIPV = 0.
> Any comments please let me know.
I''ll get to commit these once the current set of regressions cleared.

Thanks for sending the original patch again (saves me from having to
dig it out of the list archives).

Jan

Jan Beulich wrote:
>>>> On 05.12.11 at 14:09, "Liu, Jinsong"
<jinsong.liu@intel.com> wrote:
>> Attached is the email we discuss last month, and 2 mce patches:
>> srar-1.patch is the patch we discussed before,
>> srar-guest-mode.patch is an additional patch w/ more strict sanity
>> checkof RIPV = EIPV = 0. Any comments please let me know.
> 
> I''ll get to commit these once the current set of regressions
cleared.
> 
> Thanks for sending the original patch again (saves me from having to
> dig it out of the list archives).
> 
> Jan
Thanks, Jan :)