Ke, Liping
2010-Apr-28 10:06 UTC
[Xen-devel] [PATCH] x86: add CMCI software injection interface
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 { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-04 13:06 UTC
[Xen-devel] 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ke, Liping
2010-May-05 01:56 UTC
[Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Frank Van Der Linden
2010-May-05 03:52 UTC
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, > cripingI 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-May-05 07:11 UTC
RE: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>-----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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-May-05 07:46 UTC
Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2010-May-05 07:53 UTC
Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2010-May-05 08:09 UTC
Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-05 08:54 UTC
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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-05 08:54 UTC
Re: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
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.._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-May-05 09:07 UTC
RE: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
>-----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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2010-May-05 09:20 UTC
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-May-05 09:34 UTC
RE: [Xen-devel] RE: [PATCH] x86: add CMCI software injection interface
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2010-Jun-07 08:12 UTC
[Xen-devel] [PATCH] x86: add CMCI software injection interface
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel