linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: x86@kernel.org, Borislav Petkov <bp@suse.de>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Len Brown <len.brown@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	linux-kernel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
	linux-edac@vger.kernel.org
Subject: [PATCH 3/3] x86/mce: include type of core when reporting a machine check error
Date: Fri,  2 Oct 2020 13:19:31 -0700	[thread overview]
Message-ID: <20201002201931.2826-4-ricardo.neri-calderon@linux.intel.com> (raw)
In-Reply-To: <20201002201931.2826-1-ricardo.neri-calderon@linux.intel.com>

In hybrid parts, each type of core reports different types of machine check
errors as the machine check error blocks are tied to different parts of the
hardware. Furthermore, errors may be different across micro-architecture
versions. Thus, in order to decode errors, userspace tools need to know the
type of core as well as the native model ID of the CPU which reported the
error.

This extra information is only included in the error report only when
running on hybrid parts. This conserves the existing behavior when running
on non-hybrid parts. Hence, legacy userspace tools running on new kernels
and hybrid hardware can still understand the format of the reported error
format.

Cc: "Ravi V Shankar" <ravi.v.shankar@intel.com>
Cc: linux-edac@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
 arch/x86/include/uapi/asm/mce.h | 1 +
 arch/x86/kernel/cpu/mce/core.c  | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/include/uapi/asm/mce.h b/arch/x86/include/uapi/asm/mce.h
index db9adc081c5a..e730572186d6 100644
--- a/arch/x86/include/uapi/asm/mce.h
+++ b/arch/x86/include/uapi/asm/mce.h
@@ -36,6 +36,7 @@ struct mce {
 	__u64 ppin;		/* Protected Processor Inventory Number */
 	__u32 microcode;	/* Microcode revision */
 	__u64 kflags;		/* Internal kernel use */
+	__u32 hybrid_info;	/* Type and native model ID in hybrid parts */
 };
 
 #define MCE_GET_RECORD_LEN   _IOR('M', 1, int)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index a6ff407dec71..ecac8d9b6070 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -143,6 +143,9 @@ noinstr void mce_setup(struct mce *m)
 	m->apicid = cpu_data(m->extcpu).initial_apicid;
 	m->mcgcap = __rdmsr(MSR_IA32_MCG_CAP);
 
+	if (this_cpu_has(X86_FEATURE_HYBRID_CPU))
+		m->hybrid_info = cpuid_eax(0x1a);
+
 	if (this_cpu_has(X86_FEATURE_INTEL_PPIN))
 		m->ppin = __rdmsr(MSR_PPIN);
 	else if (this_cpu_has(X86_FEATURE_AMD_PPIN))
@@ -264,6 +267,10 @@ static void __print_mce(struct mce *m)
 	pr_emerg(HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x microcode %x\n",
 		m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid,
 		m->microcode);
+
+	if (this_cpu_has(X86_FEATURE_HYBRID_CPU))
+		pr_emerg(HW_ERR "HYBRID_TYPE %x HYBRID_NATIVE_MODEL_ID %x\n",
+			 m->hybrid_info >> 24, m->hybrid_info & 0xffffff);
 }
 
 static void print_mce(struct mce *m)
-- 
2.17.1


  parent reply	other threads:[~2020-10-02 20:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 20:19 [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs Ricardo Neri
2020-10-02 20:19 ` [PATCH 1/3] x86/cpufeatures: Enumerate hybrid CPU feature bit Ricardo Neri
2020-10-02 20:19 ` [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86 Ricardo Neri
2020-10-02 20:34   ` Borislav Petkov
2020-10-02 21:02     ` Ricardo Neri
2020-10-02 21:03       ` Borislav Petkov
2020-10-02 23:41         ` Ricardo Neri
2020-10-02 20:19 ` Ricardo Neri [this message]
2020-10-03  1:39 ` [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs Thomas Gleixner
2020-10-03  2:17   ` Luck, Tony
2020-10-03  9:04     ` Borislav Petkov
2020-10-06  0:24       ` Ricardo Neri
2020-10-03 10:46     ` Thomas Gleixner
2020-10-03 14:39       ` Peter Zijlstra
2020-10-06  0:21       ` Ricardo Neri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201002201931.2826-4-ricardo.neri-calderon@linux.intel.com \
    --to=ricardo.neri-calderon@linux.intel.com \
    --cc=bp@suse.de \
    --cc=len.brown@intel.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).