[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/19] x86/mce: always write 0 to MSR_IA32_MCG_STATUS on Intel CPU
On 02/17/2017 10:13 AM, Jan Beulich wrote: On 17.02.17 at 16:01, <boris.ostrovsky@xxxxxxxxxx> wrote:On 02/17/2017 05:26 AM, Jan Beulich wrote:On 17.02.17 at 07:39, <haozhong.zhang@xxxxxxxxx> wrote:--- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -538,7 +538,14 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs) gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS); if ((gstatus & MCG_STATUS_MCIP) != 0) { mce_printk(MCE_CRITICAL, "MCE: Clear MCIP@ last step"); - mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus & ~MCG_STATUS_MCIP); + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + /* + * Intel SDM 3: An attempt to write to IA32_MCG_STATUS + * with any value other than 0 would result in #GP. + */ + mca_wrmsr(MSR_IA32_MCG_STATUS, 0); + else + mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus & ~MCG_STATUS_MCIP);I think this wants to be the other way around: Write zero in the common case, and make an exception for AMD (and that only if on AMD it's really useful to write other than plain zero). Boris, Suravee, can you provide some input here please?I don't see anything stating that writing non-zero values can result in an exception of any sort. But I am only going by what I see in the documentation.But the question was the other way around: Is there a need to clear only the MCIP bit, or can we as well write plain zero to the MSR (allowing the conditional to be dropped). I don't see any indication of problems writing any of the three bits with any value so assuming the other two bits have been handled by now (as they were before this series) I don't see any issues. But I think Suravee would be a better person to answer this, perhaps after checking with HW people. -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |