linux-edac.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yazen Ghannam <Yazen.Ghannam@amd.com>
To: linux-edac@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, tony.luck@intel.com,
	x86@kernel.org, Smita.KoralahalliChannabasappa@amd.com,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	stable@vger.kernel.org
Subject: [PATCH 1/2] x86/MCE: Always save CS register on AMD Zen IF errors
Date: Tue,  4 May 2021 17:47:11 +0000	[thread overview]
Message-ID: <20210504174712.27675-2-Yazen.Ghannam@amd.com> (raw)
In-Reply-To: <20210504174712.27675-1-Yazen.Ghannam@amd.com>

From: Yazen Ghannam <yazen.ghannam@amd.com>

The Instruction Fetch (IF) units on AMD Zen-based systems do not
guarantee a synchronous #MC is delivered. Therefore, MCG_STATUS[EIPV|RIPV]
will not be set. However, the microarchitecture does guarantee that the
exception is delivered within the same context. In other words, the
exact rIP is not known, but the context is known to not have changed.

There is no architecturally-defined method to determine this behavior.

The Code Segment (CS) register is always valid on AMD Zen-based IF units
regardless of the value of MCG_STATUS[EIPV|RIPV].

Add a quirk for all current Zen-based systems to save the CS register
for the IF banks.

This is needed to properly determine the context of the error.
Otherwise, the severity grading function will assume the context is
IN_KERNEL due to the m->cs value being 0 (the initialized value). This
leads to unnecessary kernel panics on data poison errors due to the
kernel believing the poison consumption occurred in kernel context.

Cc: <stable@vger.kernel.org>
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
---
 arch/x86/kernel/cpu/mce/amd.c      | 17 +++++++++++++++++
 arch/x86/kernel/cpu/mce/core.c     |  7 +++++++
 arch/x86/kernel/cpu/mce/internal.h |  2 ++
 3 files changed, 26 insertions(+)

diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index e486f96b3cb3..141dcdd857b5 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -180,6 +180,23 @@ static struct smca_hwid smca_hwid_mcatypes[] = {
 struct smca_bank smca_banks[MAX_NR_BANKS];
 EXPORT_SYMBOL_GPL(smca_banks);
 
+/*
+ * Zen-based Instruction Fetch Units set EIPV=RIPV=0 on poison consumption
+ * errors (XEC = 12). However, the context is still valid, so save the CS
+ * register for later use.
+ */
+void quirk_zen_ifu(int bank, struct mce *m, struct pt_regs *regs)
+{
+	if (smca_get_bank_type(bank) != SMCA_IF)
+		return;
+	if ((m->mcgstatus & (MCG_STATUS_EIPV|MCG_STATUS_RIPV)) != 0)
+		return;
+	if (((m->status >> 16) & 0x1F) != 12)
+		return;
+
+	m->cs = regs->cs;
+}
+
 /*
  * In SMCA enabled processors, we can have multiple banks for a given IP type.
  * So to define a unique name for each bank, we use a temp c-string to append
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index bf7fe87a7e88..308fb644b94a 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1754,6 +1754,13 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 *c)
 		if (c->x86 == 0x15 && c->x86_model <= 0xf)
 			mce_flags.overflow_recov = 1;
 
+		if (c->x86 == 0x17 || c->x86 == 0x19)
+			quirk_no_way_out = quirk_zen_ifu;
+	}
+
+	if (c->x86_vendor == X86_VENDOR_HYGON) {
+		if (c->x86 == 0x18)
+			quirk_no_way_out = quirk_zen_ifu;
 	}
 
 	if (c->x86_vendor == X86_VENDOR_INTEL) {
diff --git a/arch/x86/kernel/cpu/mce/internal.h b/arch/x86/kernel/cpu/mce/internal.h
index 88dcc79cfb07..656d5d6c9783 100644
--- a/arch/x86/kernel/cpu/mce/internal.h
+++ b/arch/x86/kernel/cpu/mce/internal.h
@@ -181,8 +181,10 @@ extern struct mca_msr_regs msr_ops;
 extern bool filter_mce(struct mce *m);
 
 #ifdef CONFIG_X86_MCE_AMD
+extern void quirk_zen_ifu(int bank, struct mce *m, struct pt_regs *regs);
 extern bool amd_filter_mce(struct mce *m);
 #else
+#define quirk_zen_ifu							NULL
 static inline bool amd_filter_mce(struct mce *m)			{ return false; };
 #endif
 
-- 
2.25.1


  reply	other threads:[~2021-05-04 17:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-04 17:47 [PATCH 0/2] AMD Zen-based IF Unit Poison Quirk Yazen Ghannam
2021-05-04 17:47 ` Yazen Ghannam [this message]
2021-05-04 17:47 ` [PATCH 2/2] x86/MCE: Don't call kill_me_now() directly Yazen Ghannam
2021-05-04 18:07   ` Luck, Tony
2021-05-04 18:29     ` Yazen Ghannam

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=20210504174712.27675-2-Yazen.Ghannam@amd.com \
    --to=yazen.ghannam@amd.com \
    --cc=Smita.KoralahalliChannabasappa@amd.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --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).