[PATCH] x86: add CMCI software injection interface

[PATCH] x86: add CMCI software injection interface

[Ke, Liping]

[-- Attachment #1.1: Type: text/plain, Size: 3248 bytes --]

Hi, all

Currently we already have MCE software injection interface.
This small patch now add CMCI software injection interface. So that CMCI error could be triggered by software on CPUs which support CMCI.
Broadcast option is used for simulating bank sharing scenario.

This patch was tested together by running mcelog in DOM0 and got expected CMCI information.

Thanks& Regards,
Criping


diff -r 37ab34d32ecf xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c   Fri Apr 23 14:39:44 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c          Fri Apr 23 14:40:00 2010 +0800
@@ -1274,6 +1274,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
        unsigned int target;
        struct xen_mc_msrinject *mc_msrinject;
        struct xen_mc_mceinject *mc_mceinject;
+       cpumask_t target_map;

        if (!IS_PRIV(v->domain) )
                 return x86_mcerr(NULL, -EPERM);
@@ -1411,6 +1412,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u

                 mc_mceinject = &op->u.mc_mceinject;
                 target = mc_mceinject->mceinj_cpunr;
+                flags = mc_mceinject->mceinj_flag;

                 if (target >= NR_CPUS)
                           return x86_mcerr("do_mca #MC: bad target", -EINVAL);
@@ -1419,12 +1421,22 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
                           return x86_mcerr("do_mca #MC: target offline", -EINVAL);

                 add_taint(TAINT_ERROR_INJECT);
-
-        if ( mce_broadcast )
-            on_each_cpu(x86_mc_mceinject, mc_mceinject, 0);
-        else
-            on_selected_cpus(cpumask_of(target), x86_mc_mceinject,
-                  mc_mceinject, 1);
+                if (flags == XEN_MC_UC) {
+                          if ( mce_broadcast )
+                                   on_each_cpu(x86_mc_mceinject, mc_mceinject, 0);
+                          else
+                                   on_selected_cpus(cpumask_of(target), x86_mc_mceinject,
+                                            mc_mceinject, 1);
+                }
+                else if (flags == XEN_MC_CE) {
+                          if (mce_broadcast)
+                                   send_IPI_mask(&cpu_online_map, CMCI_APIC_VECTOR);
+                          else {
+                                   cpus_clear(target_map);
+                                   cpu_set(target, target_map);
+                                   send_IPI_mask(&target_map, CMCI_APIC_VECTOR);
+                          }
+                }
                 break;

        default:
diff -r 37ab34d32ecf xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h Fri Apr 23 14:39:44 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h        Fri Apr 23 14:40:00 2010 +0800
@@ -400,8 +400,11 @@ struct xen_mc_msrinject {
 #define MC_MSRINJ_F_INTERPOSE   0x1

 #define XEN_MC_mceinject    5
+#define XEN_MC_UC           0
+#define XEN_MC_CE           1
 struct xen_mc_mceinject {
-        unsigned int mceinj_cpunr;      /* target processor id */
+       uint32_t mceinj_cpunr;      /* target processor id */
+       uint32_t mceinj_flag;       /* UC error or CE error flag */
 };

 struct xen_mc {

[-- Attachment #1.2: Type: text/html, Size: 13669 bytes --]

[-- Attachment #2: cmci_inject.patch --]
[-- Type: application/octet-stream, Size: 2417 bytes --]

This small patch now add CMCI software injection interface.
So that CMCI error could be triggered by software on CPUs 
which support CMCI.

Signed-off-by: Yunhong Jiang<yunhong.jiang@intel.com>
Signed-off-by: Liping Ke <liping.ke@intel.com>

diff -r 37ab34d32ecf xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 23 14:39:44 2010 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Fri Apr 23 14:40:00 2010 +0800
@@ -1274,6 +1274,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
 	unsigned int target;
 	struct xen_mc_msrinject *mc_msrinject;
 	struct xen_mc_mceinject *mc_mceinject;
+	cpumask_t target_map;
 
 	if (!IS_PRIV(v->domain) )
 		return x86_mcerr(NULL, -EPERM);
@@ -1411,6 +1412,7 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
 
 		mc_mceinject = &op->u.mc_mceinject;
 		target = mc_mceinject->mceinj_cpunr;
+		flags = mc_mceinject->mceinj_flag;
 
 		if (target >= NR_CPUS)
 			return x86_mcerr("do_mca #MC: bad target", -EINVAL);
@@ -1419,12 +1421,22 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
 			return x86_mcerr("do_mca #MC: target offline", -EINVAL);
 
 		add_taint(TAINT_ERROR_INJECT);
-
-        if ( mce_broadcast )
-            on_each_cpu(x86_mc_mceinject, mc_mceinject, 0);
-        else
-            on_selected_cpus(cpumask_of(target), x86_mc_mceinject,
-                  mc_mceinject, 1);
+		if (flags == XEN_MC_UC) {
+			if ( mce_broadcast )
+				on_each_cpu(x86_mc_mceinject, mc_mceinject, 0);
+			else
+				on_selected_cpus(cpumask_of(target), x86_mc_mceinject,
+					mc_mceinject, 1);
+		}
+		else if (flags == XEN_MC_CE) {
+			if (mce_broadcast)
+				send_IPI_mask(&cpu_online_map, CMCI_APIC_VECTOR);
+			else {
+				cpus_clear(target_map);
+				cpu_set(target, target_map);
+				send_IPI_mask(&target_map, CMCI_APIC_VECTOR);
+			}
+		}
 		break;
 
 	default:
diff -r 37ab34d32ecf xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Fri Apr 23 14:39:44 2010 +0800
+++ b/xen/include/public/arch-x86/xen-mca.h	Fri Apr 23 14:40:00 2010 +0800
@@ -400,8 +400,11 @@ struct xen_mc_msrinject {
 #define MC_MSRINJ_F_INTERPOSE   0x1
 
 #define XEN_MC_mceinject    5
+#define XEN_MC_UC           0
+#define XEN_MC_CE           1
 struct xen_mc_mceinject {
-	unsigned int mceinj_cpunr;      /* target processor id */
+	uint32_t mceinj_cpunr;      /* target processor id */
+	uint32_t mceinj_flag;       /* UC error or CE error flag */
 };
 
 struct xen_mc {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] x86: add CMCI software injection interface

[Keir Fraser]

On 28/04/2010 11:06, "Ke, Liping" <liping.ke@intel.com> wrote:

> Hi, all
>  
> Currently we already have MCE software injection interface.
> This small patch now add CMCI software injection interface. So that CMCI error
> could be triggered by software on CPUs which support CMCI.
> Broadcast option is used for simulating bank sharing scenario.
>  
> This patch was tested together by running mcelog in DOM0 and got expected CMCI
> information.

Applied, but then reverted as I realised it appears to change Xen's MCE ABI
without consideration of backward compatibility. Obviously that is not
acceptable. 

It seems that generally you guys have issues with the existing machine-check
interfaces, and your inability to modify them now they are a fixed part of
the ABI. Do we need to discuss ways to work around this in a way that
doesn't break older guests?

 -- Keir

RE: [PATCH] x86: add CMCI software injection interface

[Ke, Liping]

Hi, Keir

Yes, we do some discussion about the interface compatibility problem before submitting. 
But we found the mceinj_cpunr below is defined as unsigned int (not uint32), so we think it may have some problem in 32/64 bit machine originally.
So we gave up the backward compatibility effort and made it as uint32_5. But if sun/oracle use this interface before, we did have some problem

So Christopher and Gavin, any suggestions for this?

Regards,
criping



struct xen_mc_mceinject {
-	unsigned int mceinj_cpunr;      /* target processor id */
+	uint32_t mceinj_cpunr;      /* target processor id */
+	uint32_t mceinj_flag;       /* UC error or CE error flag */
 };


-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] 
Sent: Tuesday, May 04, 2010 9:06 PM
To: Ke, Liping; Jiang, Yunhong
Cc: xen-devel@lists.xensource.com; Christoph Egger
Subject: Re: [PATCH] x86: add CMCI software injection interface

On 28/04/2010 11:06, "Ke, Liping" <liping.ke@intel.com> wrote:

> Hi, all
>  
> Currently we already have MCE software injection interface.
> This small patch now add CMCI software injection interface. So that CMCI error
> could be triggered by software on CPUs which support CMCI.
> Broadcast option is used for simulating bank sharing scenario.
>  
> This patch was tested together by running mcelog in DOM0 and got expected CMCI
> information.

Applied, but then reverted as I realised it appears to change Xen's MCE ABI
without consideration of backward compatibility. Obviously that is not
acceptable. 

It seems that generally you guys have issues with the existing machine-check
interfaces, and your inability to modify them now they are a fixed part of
the ABI. Do we need to discuss ways to work around this in a way that
doesn't break older guests?

 -- Keir

Re: RE: [PATCH] x86: add CMCI software injection interface

[Frank Van Der Linden]

On 5/4/10 7:56 PM, Ke, Liping wrote:
> Hi, Keir
>
> Yes, we do some discussion about the interface compatibility problem before submitting.
> But we found the mceinj_cpunr below is defined as unsigned int (not uint32), so we think it may have some problem in 32/64 bit machine originally.
> So we gave up the backward compatibility effort and made it as uint32_5. But if sun/oracle use this interface before, we did have some problem
>
> So Christopher and Gavin, any suggestions for this?
>
> Regards,
> criping

I have no problems with this change. dom0/Xen should match in version 
anyway. There have been ABI breakages in the dom0/Xen interface before. 
You can bump the xen MCE hypercall version if you wish..

- Frank

RE: RE: [PATCH] x86: add CMCI software injection interface

[Jiang, Yunhong]

>-----Original Message-----
>From: Frank Van Der Linden [mailto:frank.van.der.linden@oracle.com]
>Sent: Wednesday, May 05, 2010 11:52 AM
>To: Ke, Liping
>Cc: Keir Fraser; Jiang, Yunhong; gavin.maltby@oracle.com; Egger;
>xen-devel@lists.xensource.com; Christoph@rcsinet11.oracle.com
>Subject: Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>
>On 5/4/10 7:56 PM, Ke, Liping wrote:
>> Hi, Keir
>>
>> Yes, we do some discussion about the interface compatibility problem before
>submitting.
>> But we found the mceinj_cpunr below is defined as unsigned int (not uint32), so we
>think it may have some problem in 32/64 bit machine originally.
>> So we gave up the backward compatibility effort and made it as uint32_5. But if
>sun/oracle use this interface before, we did have some problem
>>
>> So Christopher and Gavin, any suggestions for this?
>>
>> Regards,
>> criping
>
>I have no problems with this change. dom0/Xen should match in version
>anyway. There have been ABI breakages in the dom0/Xen interface before.
>You can bump the xen MCE hypercall version if you wish..

Maybe another method is to add a new do_mca command for the CMCI, like 
#define XEN_MC_cmci_inject    6

Of course, we can update the interface version, to make the new command will only be supported in new version. So that when new dom0 will not get un-expected result when running in old xen hypervisor.
Any idea?

Thanks
--jyh

>
>- Frank

Re: RE: [PATCH] x86: add CMCI software injection interface

[Keir Fraser]

On 05/05/2010 08:11, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:

> Maybe another method is to add a new do_mca command for the CMCI, like
> #define XEN_MC_cmci_inject    6
> 
> Of course, we can update the interface version, to make the new command will
> only be supported in new version. So that when new dom0 will not get
> un-expected result when running in old xen hypervisor.

To be honest either of these is fine with me. I expect Christoph will prefer
the former option, but actually so long as older dom0 kernels fail-safe on
the MCE stuff that would be good by me too. Weird behaviours and odd
failures from older guests is what we absolutely want to avoid.

If going with the former option it would be good to think ahead in your
designs and make sure you end up adding the smallest possible number of new
XEN_MC_* commands. It could easily become a real mess I'm sure.

 -- Keir

RE: RE: [PATCH] x86: add CMCI software injection interface

[Jiang, Yunhong]

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
>Sent: Wednesday, May 05, 2010 4:54 PM
>To: Jiang, Yunhong; Frank Van Der Linden; Ke, Liping
>Cc: Christoph@rcsinet11.oracle.com; Egger; xen-devel@lists.xensource.com;
>gavin.maltby@oracle.com
>Subject: Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>
>On 05/05/2010 08:11, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:
>
>> Maybe another method is to add a new do_mca command for the CMCI, like
>> #define XEN_MC_cmci_inject    6
>>
>> Of course, we can update the interface version, to make the new command will
>> only be supported in new version. So that when new dom0 will not get
>> un-expected result when running in old xen hypervisor.
>
>To be honest either of these is fine with me. I expect Christoph will prefer
>the former option, but actually so long as older dom0 kernels fail-safe on
>the MCE stuff that would be good by me too. Weird behaviours and odd
>failures from older guests is what we absolutely want to avoid.
>
>If going with the former option it would be good to think ahead in your
>designs and make sure you end up adding the smallest possible number of new
>XEN_MC_* commands. It could easily become a real mess I'm sure.

"either of these"? Maybe I didn't express my idea clearly. I didn't propose two options. I just suggest to use a new command for this purpose. And we can update the version number if needed.

BTW, as currently Xen already will return -EINVAL for not-support command (i.e. <= 5), maybe the version number update is not needed. ( the -EINVAL may be not good as -ENOSYS).

--jyh
>
> -- Keir
>

Re: RE: [PATCH] x86: add CMCI software injection interface

[Keir Fraser]

On 05/05/2010 10:07, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:

>> If going with the former option it would be good to think ahead in your
>> designs and make sure you end up adding the smallest possible number of new
>> XEN_MC_* commands. It could easily become a real mess I'm sure.
> 
> "either of these"? Maybe I didn't express my idea clearly. I didn't propose
> two options. I just suggest to use a new command for this purpose. And we can
> update the version number if needed.
> 
> BTW, as currently Xen already will return -EINVAL for not-support command
> (i.e. <= 5), maybe the version number update is not needed. ( the -EINVAL may
> be not good as -ENOSYS).

Oh, sorry, I thought you were expressing either-or. If you add a new command
then you do not update the version number: that would pointlessly disable
MCE on older guests.

 -- Keir

RE: RE: [PATCH] x86: add CMCI software injection interface

[Jiang, Yunhong]

Ok, we will do it this way.

--jyh

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
>Sent: Wednesday, May 05, 2010 5:21 PM
>To: Jiang, Yunhong; Frank Van Der Linden; Ke, Liping
>Cc: Christoph@rcsinet11.oracle.com; Egger; xen-devel@lists.xensource.com;
>gavin.maltby@oracle.com
>Subject: Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>
>On 05/05/2010 10:07, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:
>
>>> If going with the former option it would be good to think ahead in your
>>> designs and make sure you end up adding the smallest possible number of new
>>> XEN_MC_* commands. It could easily become a real mess I'm sure.
>>
>> "either of these"? Maybe I didn't express my idea clearly. I didn't propose
>> two options. I just suggest to use a new command for this purpose. And we can
>> update the version number if needed.
>>
>> BTW, as currently Xen already will return -EINVAL for not-support command
>> (i.e. <= 5), maybe the version number update is not needed. ( the -EINVAL may
>> be not good as -ENOSYS).
>
>Oh, sorry, I thought you were expressing either-or. If you add a new command
>then you do not update the version number: that would pointlessly disable
>MCE on older guests.
>
> -- Keir
>

[PATCH] x86: add CMCI software injection interface

[Jiang, Yunhong]

[-- Attachment #1: Type: text/plain, Size: 6812 bytes --]

This patch add software CMCI injection interface for test support.

A new command is added. User can set the target CPU map, since the CMCI can be triggered on some specific CPUs.
Please be noticed that the xenctl_cpumap structure is moved from domctl.h to xen.h.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

Thanks
--jyh

 arch/x86/cpu/mcheck/mce.c         |   53 ++++++++++++++++++++++++++++++++++++++
 include/public/arch-x86/xen-mca.h |   17 ++++++++++++
 include/public/domctl.h           |    5 ---
 include/public/xen.h              |    8 +++++
 include/xlat.lst                  |    1 
 5 files changed, 79 insertions(+), 5 deletions(-)


diff -r 80ff89b09389 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Sat May 15 09:22:55 2010 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu May 20 17:01:01 2010 +0800
@@ -1179,6 +1179,12 @@ static void x86_mc_mceinject(void *data)
 	__asm__ __volatile__("int $0x12");
 }
 
+static void x86_cmci_inject(void *data)
+{
+	printk("Simulating CMCI on cpu %d\n", smp_processor_id());
+	__asm__ __volatile__("int $0xf7");
+}
+
 #if BITS_PER_LONG == 64
 
 #define	ID2COOKIE(id)	((mctelem_cookie_t)(id))
@@ -1217,6 +1223,7 @@ CHECK_FIELD_(struct, mc_physcpuinfo, ncp
 CHECK_FIELD_(struct, mc_physcpuinfo, ncpus);
 # define CHECK_compat_mc_physcpuinfo struct mc_physcpuinfo
 
+#define CHECK_compat_mc_inject_v2   struct mc_inject_v2
 CHECK_mc;
 # undef CHECK_compat_mc_fetch
 # undef CHECK_compat_mc_physcpuinfo
@@ -1426,12 +1433,58 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
                   mc_mceinject, 1);
 		break;
 
+	case XEN_MC_inject_v2:
+	{
+		cpumask_t cpumap;
+
+		if (nr_mce_banks == 0)
+			return x86_mcerr("do_mca #MC", -ENODEV);
+
+		if ( op->u.mc_inject_v2.flags & XEN_MC_INJECT_CPU_BROADCAST )
+			cpus_copy(cpumap, cpu_online_map);
+		else
+		{
+			int gcw;
+
+			cpus_clear(cpumap);
+			xenctl_cpumap_to_cpumask(&cpumap,
+					&op->u.mc_inject_v2.cpumap);
+			gcw = cpus_weight(cpumap);
+			cpus_and(cpumap, cpu_online_map, cpumap);
+
+			if ( cpus_empty(cpumap) )
+				return x86_mcerr("No online CPU passed\n", -EINVAL);
+			else if ( gcw != cpus_weight(cpumap) )
+				dprintk(XENLOG_INFO,
+					"Not all required CPUs are online\n");
+		}
+
+		switch (op->u.mc_inject_v2.flags & XEN_MC_INJECT_TYPE_MASK)
+		{
+		case XEN_MC_INJECT_TYPE_MCE:
+			if ( mce_broadcast &&
+			  !cpus_equal(cpumap, cpu_online_map) )
+				printk("Not trigger MCE on all CPUs, may HANG!\n");
+			on_selected_cpus(&cpumap, x86_mc_mceinject, NULL, 1);
+			break;
+		case XEN_MC_INJECT_TYPE_CMCI:
+			if ( !cmci_support )
+				return x86_mcerr(
+				"No CMCI supported in platform\n", -EINVAL);
+			on_selected_cpus(&cpumap, x86_cmci_inject, NULL, 1);
+			break;
+		default:
+			return x86_mcerr("Wrong mca type\n", -EINVAL);
+		}
+		break;
+	}
 	default:
 		return x86_mcerr("do_mca: bad command", -EINVAL);
 	}
 
 	return ret;
 }
+
 void set_poll_bankmask(struct cpuinfo_x86 *c)
 {
 
diff -r 80ff89b09389 xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/public/arch-x86/xen-mca.h	Thu May 20 17:03:59 2010 +0800
@@ -404,6 +404,20 @@ struct xen_mc_mceinject {
 	unsigned int mceinj_cpunr;      /* target processor id */
 };
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define XEN_MC_inject_v2        6
+#define XEN_MC_INJECT_TYPE_MASK     0x7
+#define XEN_MC_INJECT_TYPE_MCE      0x0
+#define XEN_MC_INJECT_TYPE_CMCI     0x1
+
+#define XEN_MC_INJECT_CPU_BROADCAST 0x8
+
+struct xen_mc_inject_v2 {
+	uint32_t flags;
+	struct xenctl_cpumap cpumap;
+};
+#endif
+
 struct xen_mc {
     uint32_t cmd;
     uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
@@ -413,6 +427,9 @@ struct xen_mc {
         struct xen_mc_physcpuinfo  mc_physcpuinfo;
         struct xen_mc_msrinject    mc_msrinject;
         struct xen_mc_mceinject    mc_mceinject;
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+        struct xen_mc_inject_v2    mc_inject_v2;
+#endif
     } u;
 };
 typedef struct xen_mc xen_mc_t;
diff -r 80ff89b09389 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/public/domctl.h	Thu May 20 14:33:37 2010 +0800
@@ -36,11 +36,6 @@
 #include "grant_table.h"
 
 #define XEN_DOMCTL_INTERFACE_VERSION 0x00000007
-
-struct xenctl_cpumap {
-    XEN_GUEST_HANDLE_64(uint8) bitmap;
-    uint32_t nr_cpus;
-};
 
 /*
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
diff -r 80ff89b09389 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/public/xen.h	Thu May 20 14:33:37 2010 +0800
@@ -696,6 +696,14 @@ __DEFINE_XEN_GUEST_HANDLE(uint64, uint64
 #ifndef XEN_GUEST_HANDLE_64
 #define XEN_GUEST_HANDLE_64(name) XEN_GUEST_HANDLE(name)
 #endif
+
+#ifndef __ASSEMBLY__
+struct xenctl_cpumap {
+    XEN_GUEST_HANDLE_64(uint8) bitmap;
+    uint32_t nr_cpus;
+};
+#endif
+
 #endif
 
 #endif /* __XEN_PUBLIC_XEN_H__ */
diff -r 80ff89b09389 xen/include/xlat.lst
--- a/xen/include/xlat.lst	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/xlat.lst	Thu May 20 14:33:37 2010 +0800
@@ -2,6 +2,7 @@
 # ! - needs translation
 # ? - needs checking
 ?	dom0_vga_console_info		xen.h
+?   xenctl_cpumap               xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
 !	start_info			xen.h



>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
>Sent: Wednesday, May 05, 2010 5:21 PM
>To: Jiang, Yunhong; Frank Van Der Linden; Ke, Liping
>Cc: Christoph@rcsinet11.oracle.com; Egger; xen-devel@lists.xensource.com;
>gavin.maltby@oracle.com
>Subject: Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>
>On 05/05/2010 10:07, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:
>
>>> If going with the former option it would be good to think ahead in your
>>> designs and make sure you end up adding the smallest possible number of new
>>> XEN_MC_* commands. It could easily become a real mess I'm sure.
>>
>> "either of these"? Maybe I didn't express my idea clearly. I didn't propose
>> two options. I just suggest to use a new command for this purpose. And we can
>> update the version number if needed.
>>
>> BTW, as currently Xen already will return -EINVAL for not-support command
>> (i.e. <= 5), maybe the version number update is not needed. ( the -EINVAL may
>> be not good as -ENOSYS).
>
>Oh, sorry, I thought you were expressing either-or. If you add a new command
>then you do not update the version number: that would pointlessly disable
>MCE on older guests.
>
> -- Keir
>


[-- Attachment #2: cmci.patch --]
[-- Type: application/octet-stream, Size: 4717 bytes --]

CMCI inject command

diff -r 80ff89b09389 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c	Sat May 15 09:22:55 2010 +0100
+++ b/xen/arch/x86/cpu/mcheck/mce.c	Thu May 20 17:01:01 2010 +0800
@@ -1179,6 +1179,12 @@ static void x86_mc_mceinject(void *data)
 	__asm__ __volatile__("int $0x12");
 }
 
+static void x86_cmci_inject(void *data)
+{
+	printk("Simulating CMCI on cpu %d\n", smp_processor_id());
+	__asm__ __volatile__("int $0xf7");
+}
+
 #if BITS_PER_LONG == 64
 
 #define	ID2COOKIE(id)	((mctelem_cookie_t)(id))
@@ -1217,6 +1223,7 @@ CHECK_FIELD_(struct, mc_physcpuinfo, ncp
 CHECK_FIELD_(struct, mc_physcpuinfo, ncpus);
 # define CHECK_compat_mc_physcpuinfo struct mc_physcpuinfo
 
+#define CHECK_compat_mc_inject_v2   struct mc_inject_v2
 CHECK_mc;
 # undef CHECK_compat_mc_fetch
 # undef CHECK_compat_mc_physcpuinfo
@@ -1426,12 +1433,58 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u
                   mc_mceinject, 1);
 		break;
 
+	case XEN_MC_inject_v2:
+	{
+		cpumask_t cpumap;
+
+		if (nr_mce_banks == 0)
+			return x86_mcerr("do_mca #MC", -ENODEV);
+
+		if ( op->u.mc_inject_v2.flags & XEN_MC_INJECT_CPU_BROADCAST )
+			cpus_copy(cpumap, cpu_online_map);
+		else
+		{
+			int gcw;
+
+			cpus_clear(cpumap);
+			xenctl_cpumap_to_cpumask(&cpumap,
+					&op->u.mc_inject_v2.cpumap);
+			gcw = cpus_weight(cpumap);
+			cpus_and(cpumap, cpu_online_map, cpumap);
+
+			if ( cpus_empty(cpumap) )
+				return x86_mcerr("No online CPU passed\n", -EINVAL);
+			else if ( gcw != cpus_weight(cpumap) )
+				dprintk(XENLOG_INFO,
+					"Not all required CPUs are online\n");
+		}
+
+		switch (op->u.mc_inject_v2.flags & XEN_MC_INJECT_TYPE_MASK)
+		{
+		case XEN_MC_INJECT_TYPE_MCE:
+			if ( mce_broadcast &&
+			  !cpus_equal(cpumap, cpu_online_map) )
+				printk("Not trigger MCE on all CPUs, may HANG!\n");
+			on_selected_cpus(&cpumap, x86_mc_mceinject, NULL, 1);
+			break;
+		case XEN_MC_INJECT_TYPE_CMCI:
+			if ( !cmci_support )
+				return x86_mcerr(
+				"No CMCI supported in platform\n", -EINVAL);
+			on_selected_cpus(&cpumap, x86_cmci_inject, NULL, 1);
+			break;
+		default:
+			return x86_mcerr("Wrong mca type\n", -EINVAL);
+		}
+		break;
+	}
 	default:
 		return x86_mcerr("do_mca: bad command", -EINVAL);
 	}
 
 	return ret;
 }
+
 void set_poll_bankmask(struct cpuinfo_x86 *c)
 {
 
diff -r 80ff89b09389 xen/include/public/arch-x86/xen-mca.h
--- a/xen/include/public/arch-x86/xen-mca.h	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/public/arch-x86/xen-mca.h	Thu May 20 17:03:59 2010 +0800
@@ -404,6 +404,20 @@ struct xen_mc_mceinject {
 	unsigned int mceinj_cpunr;      /* target processor id */
 };
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define XEN_MC_inject_v2        6
+#define XEN_MC_INJECT_TYPE_MASK     0x7
+#define XEN_MC_INJECT_TYPE_MCE      0x0
+#define XEN_MC_INJECT_TYPE_CMCI     0x1
+
+#define XEN_MC_INJECT_CPU_BROADCAST 0x8
+
+struct xen_mc_inject_v2 {
+	uint32_t flags;
+	struct xenctl_cpumap cpumap;
+};
+#endif
+
 struct xen_mc {
     uint32_t cmd;
     uint32_t interface_version; /* XEN_MCA_INTERFACE_VERSION */
@@ -413,6 +427,9 @@ struct xen_mc {
         struct xen_mc_physcpuinfo  mc_physcpuinfo;
         struct xen_mc_msrinject    mc_msrinject;
         struct xen_mc_mceinject    mc_mceinject;
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+        struct xen_mc_inject_v2    mc_inject_v2;
+#endif
     } u;
 };
 typedef struct xen_mc xen_mc_t;
diff -r 80ff89b09389 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/public/domctl.h	Thu May 20 14:33:37 2010 +0800
@@ -36,11 +36,6 @@
 #include "grant_table.h"
 
 #define XEN_DOMCTL_INTERFACE_VERSION 0x00000007
-
-struct xenctl_cpumap {
-    XEN_GUEST_HANDLE_64(uint8) bitmap;
-    uint32_t nr_cpus;
-};
 
 /*
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
diff -r 80ff89b09389 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/public/xen.h	Thu May 20 14:33:37 2010 +0800
@@ -696,6 +696,14 @@ __DEFINE_XEN_GUEST_HANDLE(uint64, uint64
 #ifndef XEN_GUEST_HANDLE_64
 #define XEN_GUEST_HANDLE_64(name) XEN_GUEST_HANDLE(name)
 #endif
+
+#ifndef __ASSEMBLY__
+struct xenctl_cpumap {
+    XEN_GUEST_HANDLE_64(uint8) bitmap;
+    uint32_t nr_cpus;
+};
+#endif
+
 #endif
 
 #endif /* __XEN_PUBLIC_XEN_H__ */
diff -r 80ff89b09389 xen/include/xlat.lst
--- a/xen/include/xlat.lst	Sat May 15 09:22:55 2010 +0100
+++ b/xen/include/xlat.lst	Thu May 20 14:33:37 2010 +0800
@@ -2,6 +2,7 @@
 # ! - needs translation
 # ? - needs checking
 ?	dom0_vga_console_info		xen.h
+?   xenctl_cpumap               xen.h
 ?	mmu_update			xen.h
 !	mmuext_op			xen.h
 !	start_info			xen.h

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: RE: [PATCH] x86: add CMCI software injection interface

[Jan Beulich]

>>> Frank Van Der Linden <frank.van.der.linden@oracle.com> 05.05.10 05:52 >>>
>I have no problems with this change. dom0/Xen should match in version 
>anyway. There have been ABI breakages in the dom0/Xen interface before. 

When was it that you last saw an incompatible change to the interface?
There shouldn't be a need to match up Dom0 and Xen versions, except
when you want support for newly added features.

Jan

Re: RE: [PATCH] x86: add CMCI software injection interface

[Christoph Egger]

On Wednesday 05 May 2010 09:46:22 Jan Beulich wrote:
> >>> Frank Van Der Linden <frank.van.der.linden@oracle.com> 05.05.10 05:52
> >>> >>>
> >
> >I have no problems with this change. dom0/Xen should match in version
> >anyway. There have been ABI breakages in the dom0/Xen interface before.
>
> When was it that you last saw an incompatible change to the interface?

Between Xen 3.3 and Xen 3.4.

> There shouldn't be a need to match up Dom0 and Xen versions, except
> when you want support for newly added features.

Correct. This is the point of backward-compatibility.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: RE: [PATCH] x86: add CMCI software injection interface

[Jan Beulich]

>>> Christoph Egger <Christoph.Egger@amd.com> 05.05.10 09:53 >>>
>On Wednesday 05 May 2010 09:46:22 Jan Beulich wrote:
>> When was it that you last saw an incompatible change to the interface?
>
>Between Xen 3.3 and Xen 3.4.

Mind pointing out what change this was? I don't recall any issues...

Jan

Re: RE: [PATCH] x86: add CMCI software injection interface

[Keir Fraser]

On 05/05/2010 04:52, "Frank Van Der Linden"
<frank.van.der.linden@oracle.com> wrote:

> I have no problems with this change. dom0/Xen should match in version
> anyway. There have been ABI breakages in the dom0/Xen interface before.

As others have already said: Very no!

 K.

> You can bump the xen MCE hypercall version if you wish..