From: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
To: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jeremy Kerr <jeremy.kerr@au1.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>
Subject: [RFC PATCH v3 04/12] Validate r1 value before going to host kernel in virtual mode.
Date: Tue, 27 Aug 2013 01:01:48 +0530 [thread overview]
Message-ID: <20130826193148.2855.95627.stgit@mars> (raw)
In-Reply-To: <20130826192616.2855.18749.stgit@mars>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
We can get machine checks from any context. We need to make sure that
we handle all of them correctly. Once we decode MCE reason and generate
MCE event, we continue in host kernel in virtual mode so that we can
log/display it later. But before going to virtual mode we need to make
sure that r1 points to host kernel stack. But machine check can occur
in any context and r1 may not always point to host kernel stack. In cases
where we can not trust r1 value, we should queue up the MCE event and return
from interrupt. This patch implements the additional checks that helps to
decide whether to deleiver machine check event to host kernel right away
or queue it up and return.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/kernel/exceptions-64s.S | 72 ++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 651a213..d82ebac 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -785,8 +785,78 @@ BEGIN_FTR_SECTION
bl .save_nvgprs
addi r3,r1,STACK_FRAME_OVERHEAD
bl .machine_check_early
+
+ /*
+ * We are now going to host kernel in V mode. We need to make sure
+ * that r1 points to host kernel stack.
+ *
+ * If we are coming from userspace then we can continue in host kernel
+ * in V mode.
+ * But if we are coming from kernel and r1 does not point to kernel
+ * stack then we can not continue, instead we return from here.
+ */
+
+ ld r12,_MSR(r1)
+ andi. r11,r12,MSR_PR /* See if coming from user. */
+ bne 3f /* continue if we are. */
+
+#ifdef CONFIG_KVM_BOOK3S_64_HV
+ /*
+ * We are coming from kernel context. Check if we are coming from
+ * guest. if yes, then we can continue. We will fall through
+ * do_kvm_200->kvmppc_interrupt which will setup r1 correctly.
+ */
+ lbz r11,HSTATE_IN_GUEST(r13)
+ cmpwi r11,0 /* Check if coming from guest */
+ bne 3f /* continue if we are. */
+
+ /*
+ * So, we did not come from guest. That leaves three possibilities:
+ * a. We come from secondary thread which just came out of nap and
+ * about to call kvm_start_guest.
+ * b. We come from secondary thread which is about to go to nap
+ * state (see kvm_no_guest()).
+ * c. We come from opal context and r1 may be pointing to opal
+ * kernel stack.
+ */
+
+ lbz r11,HSTATE_HWTHREAD_STATE(r13)
+ cmpwi r11,KVM_HWTHREAD_IN_NAP /* Was it nap-ing? or about to */
+ beq 0f /* Queue up event and return from interrupt */
+#endif
+
+ /*
+ * So far we checked all possible situations where we can not
+ * trust r1. Now we can trust r1.
+ * r1 < 0 r1 points to host kernel stack
+ * r1 > 0 r1 points to opal stack
+ */
+ ld r11,GPR1(r1)
+ cmpdi r11,0 /* check if r1 is in kernel. */
+ blt+ 3f /* Continue if yes. */
+
+ /*
+ * r1 points to opal stack. Queue up the MCE event and return
+ * from the interrupt. But before that, check if this is an
+ * un-recoverable exception. If yes, then stay on emergency
+ * stack and panic.
+ */
+0: andi. r11,r12,MSR_RI
+ bne 2f
+
+1: addi r3,r1,STACK_FRAME_OVERHEAD
+ bl .unrecoverable_exception
+ b 1b
+
+ /*
+ * Return from MC interrupt.
+ * TODO: Queue up the MCE event so that we can log it later.
+ */
+2: MACHINE_CHECK_HANDLER_WINDUP
+ rfid
+
/* Deliver the machine check to host kernel in V mode. */
- MACHINE_CHECK_HANDLER_WINDUP
+3: MACHINE_CHECK_HANDLER_WINDUP
b machine_check_pSeries
END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
next prev parent reply other threads:[~2013-08-26 19:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-26 19:31 [RFC PATCH v3 00/12] Machine check handling in linux host Mahesh J Salgaonkar
2013-08-26 19:31 ` [RFC PATCH v3 01/12] powerpc/book3s: Split the common exception prolog logic into two section Mahesh J Salgaonkar
2013-09-09 4:29 ` Paul Mackerras
2013-08-26 19:31 ` [RFC PATCH v3 02/12] powerpc/book3s: Introduce exclusive emergency stack for machine check exception Mahesh J Salgaonkar
2013-09-09 4:30 ` Paul Mackerras
2013-08-26 19:31 ` [RFC PATCH v3 03/12] powerpc/book3s: handle machine check in Linux host Mahesh J Salgaonkar
2013-09-09 4:52 ` Paul Mackerras
2013-08-26 19:31 ` Mahesh J Salgaonkar [this message]
2013-09-09 5:29 ` [RFC PATCH v3 04/12] Validate r1 value before going to host kernel in virtual mode Paul Mackerras
2013-09-09 9:26 ` Benjamin Herrenschmidt
2013-08-26 19:31 ` [RFC PATCH v3 05/12] powerpc/book3s: Introduce a early machine check hook in cpu_spec Mahesh J Salgaonkar
2013-09-09 5:33 ` Paul Mackerras
2013-08-26 19:32 ` [RFC PATCH v3 06/12] powerpc/book3s: Add flush_tlb operation " Mahesh J Salgaonkar
2013-09-09 5:36 ` Paul Mackerras
2013-08-26 19:32 ` [RFC PATCH v3 07/12] powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power7 Mahesh J Salgaonkar
2013-09-09 6:00 ` Paul Mackerras
2013-08-26 19:32 ` [RFC PATCH v3 08/12] powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power8 Mahesh J Salgaonkar
2013-09-09 6:01 ` Paul Mackerras
2013-08-26 19:32 ` [RFC PATCH v3 09/12] powerpc/book3s: Decode and save machine check event Mahesh J Salgaonkar
2013-08-26 19:32 ` [RFC PATCH v3 10/12] Queue up and process delayed MCE events Mahesh J Salgaonkar
2013-08-26 19:32 ` [RFC PATCH v3 11/12] powerpc/powernv: Remove machine check handling in OPAL Mahesh J Salgaonkar
2013-08-26 19:32 ` [RFC PATCH v3 12/12] powerpc/powernv: Machine check exception handling Mahesh J Salgaonkar
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=20130826193148.2855.95627.stgit@mars \
--to=mahesh@linux.vnet.ibm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=jeremy.kerr@au1.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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).