Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1541376 > unrolled thread

[RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs

Started byChristophe Leroy <christophe.leroy@c-s.fr>
First post2016-12-13 19:30 +0100
Last post2016-12-14 09:50 +0100
Articles 5 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs Christophe Leroy <christophe.leroy@c-s.fr> - 2016-12-13 19:30 +0100
    Re: [RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs Segher Boessenkool <segher@kernel.crashing.org> - 2016-12-13 20:50 +0100
      Re: [RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs christophe leroy <christophe.leroy@c-s.fr> - 2016-12-13 21:50 +0100
        Re: [RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs Segher Boessenkool <segher@kernel.crashing.org> - 2016-12-14 00:00 +0100
          Re: [RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs Peter Zijlstra <peterz@infradead.org> - 2016-12-14 09:50 +0100

#1541376 — [RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs

FromChristophe Leroy <christophe.leroy@c-s.fr>
Date2016-12-13 19:30 +0100
Subject[RFC 1/2] powerpc/32: Unset MSR RI in exception epilogs
Message-ID<sNZZT-4x7-21@gated-at.bofh.it>
At exception prologs, once SRR0 and SRR1 have been saved, MSR RI is
set to mark the interrupt as recoverable.

MSR RI has to be unset before writing into SRR0 and SRR1 at exception
epilogs.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 arch/powerpc/include/asm/ppc_asm.h | 6 ++++++
 arch/powerpc/include/asm/reg_8xx.h | 1 +
 arch/powerpc/kernel/entry_32.S     | 5 +++++
 3 files changed, 12 insertions(+)

diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index 359c443..493cb97 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -514,6 +514,12 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
 #define MTMSR_EERI(reg)	mtmsr	reg
 #endif
 
+#ifdef CONFIG_PPC_8xx
+#define SET_MSR_NRI(r)	mtspr	SPRN_NRI,r
+#else
+#define SET_MSR_NRI(r)	mfmsr r; rlwinm r,r,0,~MSR_RI; MTMSRD(r)
+#endif
+
 #endif /* __KERNEL__ */
 
 /* The boring bits... */
diff --git a/arch/powerpc/include/asm/reg_8xx.h b/arch/powerpc/include/asm/reg_8xx.h
index c52725b..52f3684 100644
--- a/arch/powerpc/include/asm/reg_8xx.h
+++ b/arch/powerpc/include/asm/reg_8xx.h
@@ -28,6 +28,7 @@
 /* Special MSR manipulation registers */
 #define SPRN_EIE	80	/* External interrupt enable (EE=1, RI=1) */
 #define SPRN_EID	81	/* External interrupt disable (EE=0, RI=1) */
+#define SPRN_NRI	82	/* Non recoverable interrupt (EE=0, RI=0) */
 
 /* Debug registers */
 #define SPRN_CMPE	152
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 980626a..b912bab 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -205,6 +205,7 @@ transfer_to_handler_cont:
 	mflr	r9
 	lwz	r11,0(r9)		/* virtual address of handler */
 	lwz	r9,4(r9)		/* where to go when done */
+	SET_MSR_NRI(r12)
 #ifdef CONFIG_TRACE_IRQFLAGS
 	lis	r12,reenable_mmu@h
 	ori	r12,r12,reenable_mmu@l
@@ -292,6 +293,7 @@ stack_ovf:
 	lis	r9,StackOverflow@ha
 	addi	r9,r9,StackOverflow@l
 	LOAD_MSR_KERNEL(r10,MSR_KERNEL)
+	SET_MSR_NRI(r12)
 	mtspr	SPRN_SRR0,r9
 	mtspr	SPRN_SRR1,r10
 	SYNC
@@ -418,6 +420,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX)
 	lwz	r7,_NIP(r1)
 	lwz	r2,GPR2(r1)
 	lwz	r1,GPR1(r1)
+	SET_MSR_NRI(r4)
 	mtspr	SPRN_SRR0,r7
 	mtspr	SPRN_SRR1,r8
 	SYNC
@@ -700,6 +703,7 @@ fast_exception_return:
 	mtcr	r10
 	lwz	r10,_LINK(r11)
 	mtlr	r10
+	SET_MSR_NRI(r10)
 	REST_GPR(10, r11)
 	mtspr	SPRN_SRR1,r9
 	mtspr	SPRN_SRR0,r12
@@ -974,6 +978,7 @@ exc_exit_restart_end:
 	.globl exc_exit_restart
 exc_exit_restart:
 	lwz	r11,_NIP(r1)
+	SET_MSR_NRI(r12)
 	lwz	r12,_MSR(r1)
 exc_exit_start:
 	mtspr	SPRN_SRR0,r11
-- 
2.10.1

[toc] | [next] | [standalone]


#1541420

FromSegher Boessenkool <segher@kernel.crashing.org>
Date2016-12-13 20:50 +0100
Message-ID<sO1fj-5cf-9@gated-at.bofh.it>
In reply to#1541376
On Tue, Dec 13, 2016 at 07:19:41PM +0100, Christophe Leroy wrote:
> At exception prologs, once SRR0 and SRR1 have been saved, MSR RI is
> set to mark the interrupt as recoverable.
> 
> MSR RI has to be unset before writing into SRR0 and SRR1 at exception
> epilogs.

Why?  What goes wrong without this?  Etc.


Segher

[toc] | [prev] | [next] | [standalone]


#1541516

Fromchristophe leroy <christophe.leroy@c-s.fr>
Date2016-12-13 21:50 +0100
Message-ID<sO2bo-5LY-51@gated-at.bofh.it>
In reply to#1541420
Le 13/12/2016 à 20:15, Segher Boessenkool a écrit :
> On Tue, Dec 13, 2016 at 07:19:41PM +0100, Christophe Leroy wrote:
>> At exception prologs, once SRR0 and SRR1 have been saved, MSR RI is
>> set to mark the interrupt as recoverable.
>>
>> MSR RI has to be unset before writing into SRR0 and SRR1 at exception
>> epilogs.
>
> Why?  What goes wrong without this?  Etc.
>
>

The following patch implements perf instruction counting using the 8xx 
debug counters. When the counter reaches 0, it fires a debug exception.
If that exception happens between the setting of srr0/srr1 and the rfi, 
values set to srr0/srr1 are lost and we end up with an Oops.

To avoid that, MSR RI has to be unset. That way, because the debug 
counters mode is set to masked mode in register LCTRL2, no debug 
interrupt will happen during that critical phase.

Christophe

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

[toc] | [prev] | [next] | [standalone]


#1541549

FromSegher Boessenkool <segher@kernel.crashing.org>
Date2016-12-14 00:00 +0100
Message-ID<sO4dc-71b-13@gated-at.bofh.it>
In reply to#1541516
On Tue, Dec 13, 2016 at 09:39:55PM +0100, christophe leroy wrote:
> Le 13/12/2016 à 20:15, Segher Boessenkool a écrit :
> >On Tue, Dec 13, 2016 at 07:19:41PM +0100, Christophe Leroy wrote:
> >>At exception prologs, once SRR0 and SRR1 have been saved, MSR RI is
> >>set to mark the interrupt as recoverable.
> >>
> >>MSR RI has to be unset before writing into SRR0 and SRR1 at exception
> >>epilogs.
> >
> >Why?  What goes wrong without this?  Etc.
> 
> The following patch implements perf instruction counting using the 8xx 
> debug counters. When the counter reaches 0, it fires a debug exception.
> If that exception happens between the setting of srr0/srr1 and the rfi, 
> values set to srr0/srr1 are lost and we end up with an Oops.
> 
> To avoid that, MSR RI has to be unset. That way, because the debug 
> counters mode is set to masked mode in register LCTRL2, no debug 
> interrupt will happen during that critical phase.

Okay, so why then do you do an expensive sequence on all other processors?


Segher

[toc] | [prev] | [next] | [standalone]


#1541764

FromPeter Zijlstra <peterz@infradead.org>
Date2016-12-14 09:50 +0100
Message-ID<sOdq9-4fU-11@gated-at.bofh.it>
In reply to#1541549
On Tue, Dec 13, 2016 at 04:54:30PM -0600, Segher Boessenkool wrote:
> On Tue, Dec 13, 2016 at 09:39:55PM +0100, christophe leroy wrote:
> > Le 13/12/2016 à 20:15, Segher Boessenkool a écrit :
> > >On Tue, Dec 13, 2016 at 07:19:41PM +0100, Christophe Leroy wrote:
> > >>At exception prologs, once SRR0 and SRR1 have been saved, MSR RI is
> > >>set to mark the interrupt as recoverable.
> > >>
> > >>MSR RI has to be unset before writing into SRR0 and SRR1 at exception
> > >>epilogs.
> > >
> > >Why?  What goes wrong without this?  Etc.
> > 
> > The following patch implements perf instruction counting using the 8xx 
> > debug counters. When the counter reaches 0, it fires a debug exception.
> > If that exception happens between the setting of srr0/srr1 and the rfi, 
> > values set to srr0/srr1 are lost and we end up with an Oops.
> > 
> > To avoid that, MSR RI has to be unset. That way, because the debug 
> > counters mode is set to masked mode in register LCTRL2, no debug 
> > interrupt will happen during that critical phase.
> 
> Okay, so why then do you do an expensive sequence on all other processors?
> 

Does ppc32 support runtime code patching? If so, you could perhaps
utilize that to only inflict the painful code sequence when perf is
enabled.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web