linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>,
	Ganesh Goudar <ganeshgr@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>
Subject: [PATCH v2 07/12] powerpc/pseries/ras: fwnmi sreset should not interlock
Date: Wed, 25 Mar 2020 20:34:05 +1000	[thread overview]
Message-ID: <20200325103410.157573-8-npiggin@gmail.com> (raw)
In-Reply-To: <20200325103410.157573-1-npiggin@gmail.com>

PAPR does not specify that fwnmi sreset should be interlocked, and
PowerVM (and therefore now QEMU) do not require it.

These "ibm,nmi-interlock" calls are ignored by firmware, but there
is a possibility that the sreset could have interrupted a machine
check and release the machine check's interlock too early, corrupting
it if another machine check came in.

This is an extremely rare case, but it should be fixed for clarity
and reducing the code executed in the sreset path. Firmware also
does not provide error information for the sreset case to look at, so
remove that comment.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
 arch/powerpc/platforms/pseries/ras.c | 48 ++++++++++++++++++++--------
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index a40598e6e525..833ae34b7fec 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -406,6 +406,20 @@ static inline struct rtas_error_log *fwnmi_get_errlog(void)
 	return (struct rtas_error_log *)local_paca->mce_data_buf;
 }
 
+static unsigned long *fwnmi_get_savep(struct pt_regs *regs)
+{
+	unsigned long savep_ra;
+
+	/* Mask top two bits */
+	savep_ra = regs->gpr[3] & ~(0x3UL << 62);
+	if (!VALID_FWNMI_BUFFER(savep_ra)) {
+		printk(KERN_ERR "FWNMI: corrupt r3 0x%016lx\n", regs->gpr[3]);
+		return NULL;
+	}
+
+	return __va(savep_ra);
+}
+
 /*
  * Get the error information for errors coming through the
  * FWNMI vectors.  The pt_regs' r3 will be updated to reflect
@@ -423,20 +437,15 @@ static inline struct rtas_error_log *fwnmi_get_errlog(void)
  */
 static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)
 {
-	unsigned long savep_ra;
 	unsigned long *savep;
 	struct rtas_error_log *h;
 
-	/* Mask top two bits */
-	savep_ra = regs->gpr[3] & ~(0x3UL << 62);
-
-	if (!VALID_FWNMI_BUFFER(savep_ra)) {
-		printk(KERN_ERR "FWNMI: corrupt r3 0x%016lx\n", regs->gpr[3]);
+	savep = fwnmi_get_savep(regs);
+	if (!savep)
 		return NULL;
-	}
 
-	savep = __va(savep_ra);
-	regs->gpr[3] = be64_to_cpu(savep[0]);	/* restore original r3 */
+	/* restore original r3 */
+	regs->gpr[3] = be64_to_cpu(savep[0]);
 
 	h = (struct rtas_error_log *)&savep[1];
 	/* Use the per cpu buffer from paca to store rtas error log */
@@ -483,11 +492,22 @@ int pSeries_system_reset_exception(struct pt_regs *regs)
 #endif
 
 	if (fwnmi_active) {
-		struct rtas_error_log *errhdr = fwnmi_get_errinfo(regs);
-		if (errhdr) {
-			/* XXX Should look at FWNMI information */
-		}
-		fwnmi_release_errinfo();
+		unsigned long *savep;
+
+		/*
+		 * Firmware (PowerVM and KVM) saves r3 to a save area like
+		 * machine check, which is not exactly what PAPR (2.9)
+		 * suggests but there is no way to detect otherwise, so this
+		 * is the interface now.
+		 *
+		 * System resets do not save any error log or require an
+		 * "ibm,nmi-interlock" rtas call to release.
+		 */
+
+		savep = fwnmi_get_savep(regs);
+		/* restore original r3 */
+		if (savep)
+			regs->gpr[3] = be64_to_cpu(savep[0]);
 	}
 
 	if (smp_handle_nmi_ipi(regs))
-- 
2.23.0


  parent reply	other threads:[~2020-03-25 10:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 10:33 [PATCH v2 00/12] powerpc/64: machine check and system reset fixes Nicholas Piggin
2020-03-25 10:33 ` [PATCH v2 01/12] powerpc/64s/exceptions: Fix in_mce accounting in unrecoverable path Nicholas Piggin
2020-03-27  3:43   ` Mahesh J Salgaonkar
2020-03-25 10:34 ` [PATCH v2 02/12] powerpc/64s/exceptions: Change irq reconcile for NMIs from reusing _DAR to RESULT Nicholas Piggin
2020-03-25 10:34 ` [PATCH v2 03/12] powerpc/64s/exceptions: machine check reconcile irq state Nicholas Piggin
2020-03-25 10:34 ` [PATCH v2 04/12] powerpc/pseries/ras: avoid calling rtas_token in NMI paths Nicholas Piggin
2020-03-27  3:50   ` Mahesh J Salgaonkar
2020-03-25 10:34 ` [PATCH v2 05/12] powerpc/pseries/ras: FWNMI_VALID off by one Nicholas Piggin
2020-03-27  3:51   ` Mahesh J Salgaonkar
2020-03-25 10:34 ` [PATCH v2 06/12] powerpc/pseries/ras: fwnmi avoid modifying r3 in error case Nicholas Piggin
2020-03-25 10:34 ` Nicholas Piggin [this message]
2020-03-25 10:34 ` [PATCH v2 08/12] powerpc/pseries: limit machine check stack to 4GB Nicholas Piggin
2020-03-27  5:24   ` Mahesh J Salgaonkar
2020-04-03 10:24     ` Nicholas Piggin
2020-03-25 10:34 ` [PATCH v2 09/12] powerpc/pseries: machine check use rtas_call_unlocked with args on stack Nicholas Piggin
2020-03-25 10:34 ` [PATCH v2 10/12] powerpc/64s: machine check interrupt update NMI accounting Nicholas Piggin
2020-03-25 10:34 ` [PATCH v2 11/12] powerpc/64s: machine check do not trace real-mode handler Nicholas Piggin
2020-03-25 10:34 ` [PATCH v2 12/12] powerpc/64s: system reset do not trace Nicholas Piggin
2020-03-26 17:23   ` Naveen N. Rao

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=20200325103410.157573-8-npiggin@gmail.com \
    --to=npiggin@gmail.com \
    --cc=ganeshgr@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mahesh@linux.vnet.ibm.com \
    /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).