[PATCH] [POWERPC] convert transfer_to_handler into a macro

[PATCH] [POWERPC] convert transfer_to_handler into a macro

[Kumar Gala]

We need to have unique transfer_to_handler paths for each exception level
that is supported.  We need to use the proper xSRR0/1 depending on which
exception level the interrupt was from.  The macro conversion lets up
templatize this code path.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---

Paul,

I request you apply this for v2.6.26.  I know its a bit late in the game
but I'd prefer to get this in so reduce churn later.  Also, I've built this
version on pmac_defconfig, ppc40x_defconfig, and ppc44x_config and compared
the objdump output to ensure that the code is identical before and after
this patch.

- k

 arch/powerpc/kernel/entry_32.S |  191 ++++++++++++++++++++++------------------
 1 files changed, 106 insertions(+), 85 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 0c8614d..7710a02 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -43,6 +43,111 @@
 #define LOAD_MSR_KERNEL(r, x)	li r,(x)
 #endif

+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#ifdef CONFIG_SMP
+#define SMP_ADJUST_GLOBAL_DBCR0						       \
+	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT);				       \
+	lwz	r9,TI_CPU(r9);						       \
+	slwi	r9,r9,3;						       \
+	add	r11,r11,r9;
+#else
+#define SMP_ADJUST_GLOBAL_DBCR0
+#endif
+#define HANDLE_DBCR							       \
+	/* Check to see if the dbcr0 register is set up to debug.  Use the     \
+	   internal debug mode bit to do this. */			       \
+	lwz	r12,THREAD_DBCR0(r12);					       \
+	andis.	r12,r12,DBCR0_IDM@h;					       \
+	beq+	3f;							       \
+	/* From user and task is ptraced - load up global dbcr0 */	       \
+	li	r12,-1;			/* clear all pending debug events */   \
+	mtspr	SPRN_DBSR,r12;						       \
+	lis	r11,global_dbcr0@ha;					       \
+	tophys(r11,r11);						       \
+	addi	r11,r11,global_dbcr0@l;					       \
+	SMP_ADJUST_GLOBAL_DBCR0;					       \
+	lwz	r12,0(r11);						       \
+	mtspr	SPRN_DBCR0,r12;						       \
+	lwz	r12,4(r11);						       \
+	addi	r12,r12,-1;						       \
+	stw	r12,4(r11);
+#else
+#define HANDLE_DBCR
+#endif
+
+#ifdef CONFIG_6xx
+#define CHECK_DOZE_NAP							       \
+	rlwinm	r9,r1,0,0,31-THREAD_SHIFT;				       \
+	tophys(r9,r9);			/* check local flags */		       \
+	lwz	r12,TI_LOCAL_FLAGS(r9);					       \
+	mtcrf	0x01,r12;						       \
+	bt-	31-TLF_NAPPING,4f;
+#define RESTORE_DOZE_NAP						       \
+4:	rlwinm	r12,r12,0,~_TLF_NAPPING;				       \
+	stw	r12,TI_LOCAL_FLAGS(r9);					       \
+	b	power_save_6xx_restore;
+#else
+#define RESTORE_DOZE_NAP
+#define CHECK_DOZE_NAP
+#endif /* CONFIG_6xx */
+
+/*
+ * This code finishes saving the registers to the exception frame
+ * and jumps to the appropriate handler for the exception, turning
+ * on address translation.
+ * Note that we rely on the caller having set cr0.eq iff the exception
+ * occurred in kernel mode (i.e. MSR:PR = 0).
+ */
+
+#define	TRANSFER_TO_HANDLER(prefix, exc_lvl_srr0, exc_lvl_srr1, exc_lvl_rfi)   \
+	.globl	prefix##transfer_to_handler_full;			       \
+prefix##transfer_to_handler_full:					       \
+	SAVE_NVGPRS(r11);						       \
+	/* fall through */						       \
+									       \
+	.globl	prefix##transfer_to_handler;				       \
+prefix##transfer_to_handler:						       \
+	stw	r2,GPR2(r11);						       \
+	stw	r12,_NIP(r11);						       \
+	stw	r9,_MSR(r11);						       \
+	andi.	r2,r9,MSR_PR;						       \
+	mfctr	r12;							       \
+	mfspr	r2,SPRN_XER;						       \
+	stw	r12,_CTR(r11);						       \
+	stw	r2,_XER(r11);						       \
+	mfspr	r12,SPRN_SPRG3;						       \
+	addi	r2,r12,-THREAD;						       \
+	tovirt(r2,r2);			/* set r2 to current */		       \
+	beq	2f;			/* if from user, fix up THREAD.regs */ \
+									       \
+	addi	r11,r1,STACK_FRAME_OVERHEAD;				       \
+	stw	r11,PT_REGS(r12);					       \
+	HANDLE_DBCR;							       \
+	b	3f;							       \
+									       \
+2:	/* if from kernel, check interrupted DOZE/NAP mode and		       \
+         * check for stack overflow					       \
+         */								       \
+	lwz	r9,KSP_LIMIT(r12);					       \
+	cmplw	r1,r9;			/* if r1 <= ksp_limit */	       \
+	ble-	stack_ovf;		/* then the kernel stack overflowed */ \
+5:									       \
+	CHECK_DOZE_NAP;							       \
+									       \
+	.globl prefix##transfer_to_handler_cont;			       \
+prefix##transfer_to_handler_cont:					       \
+3:									       \
+	mflr	r9;							       \
+	lwz	r11,0(r9);		/* virtual address of handler */       \
+	lwz	r9,4(r9);		/* where to go when done */	       \
+	mtspr	exc_lvl_srr0,r11;					       \
+	mtspr	exc_lvl_srr1,r10;					       \
+	mtlr	r9;							       \
+	SYNC;								       \
+	exc_lvl_rfi;			/* jump to handler, enable MMU */      \
+									       \
+	RESTORE_DOZE_NAP;
+
 #ifdef CONFIG_BOOKE
 #include "head_booke.h"
 #define TRANSFER_TO_HANDLER_EXC_LEVEL(exc_level)	\
@@ -80,91 +185,7 @@ crit_transfer_to_handler:
 	/* fall through */
 #endif

-/*
- * This code finishes saving the registers to the exception frame
- * and jumps to the appropriate handler for the exception, turning
- * on address translation.
- * Note that we rely on the caller having set cr0.eq iff the exception
- * occurred in kernel mode (i.e. MSR:PR = 0).
- */
-	.globl	transfer_to_handler_full
-transfer_to_handler_full:
-	SAVE_NVGPRS(r11)
-	/* fall through */
-
-	.globl	transfer_to_handler
-transfer_to_handler:
-	stw	r2,GPR2(r11)
-	stw	r12,_NIP(r11)
-	stw	r9,_MSR(r11)
-	andi.	r2,r9,MSR_PR
-	mfctr	r12
-	mfspr	r2,SPRN_XER
-	stw	r12,_CTR(r11)
-	stw	r2,_XER(r11)
-	mfspr	r12,SPRN_SPRG3
-	addi	r2,r12,-THREAD
-	tovirt(r2,r2)			/* set r2 to current */
-	beq	2f			/* if from user, fix up THREAD.regs */
-	addi	r11,r1,STACK_FRAME_OVERHEAD
-	stw	r11,PT_REGS(r12)
-#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
-	/* Check to see if the dbcr0 register is set up to debug.  Use the
-	   internal debug mode bit to do this. */
-	lwz	r12,THREAD_DBCR0(r12)
-	andis.	r12,r12,DBCR0_IDM@h
-	beq+	3f
-	/* From user and task is ptraced - load up global dbcr0 */
-	li	r12,-1			/* clear all pending debug events */
-	mtspr	SPRN_DBSR,r12
-	lis	r11,global_dbcr0@ha
-	tophys(r11,r11)
-	addi	r11,r11,global_dbcr0@l
-#ifdef CONFIG_SMP
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
-	lwz	r9,TI_CPU(r9)
-	slwi	r9,r9,3
-	add	r11,r11,r9
-#endif
-	lwz	r12,0(r11)
-	mtspr	SPRN_DBCR0,r12
-	lwz	r12,4(r11)
-	addi	r12,r12,-1
-	stw	r12,4(r11)
-#endif
-	b	3f
-
-2:	/* if from kernel, check interrupted DOZE/NAP mode and
-         * check for stack overflow
-         */
-	lwz	r9,KSP_LIMIT(r12)
-	cmplw	r1,r9			/* if r1 <= ksp_limit */
-	ble-	stack_ovf		/* then the kernel stack overflowed */
-5:
-#ifdef CONFIG_6xx
-	rlwinm	r9,r1,0,0,31-THREAD_SHIFT
-	tophys(r9,r9)			/* check local flags */
-	lwz	r12,TI_LOCAL_FLAGS(r9)
-	mtcrf	0x01,r12
-	bt-	31-TLF_NAPPING,4f
-#endif /* CONFIG_6xx */
-	.globl transfer_to_handler_cont
-transfer_to_handler_cont:
-3:
-	mflr	r9
-	lwz	r11,0(r9)		/* virtual address of handler */
-	lwz	r9,4(r9)		/* where to go when done */
-	mtspr	SPRN_SRR0,r11
-	mtspr	SPRN_SRR1,r10
-	mtlr	r9
-	SYNC
-	RFI				/* jump to handler, enable MMU */
-
-#ifdef CONFIG_6xx
-4:	rlwinm	r12,r12,0,~_TLF_NAPPING
-	stw	r12,TI_LOCAL_FLAGS(r9)
-	b	power_save_6xx_restore
-#endif
+	TRANSFER_TO_HANDLER(, SPRN_SRR0, SPRN_SRR1, RFI);

 /*
  * On kernel stack overflow, load up an initial stack pointer
-- 
1.5.4.1

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Scott Wood]

On Tue, Apr 29, 2008 at 08:56:56AM -0500, Kumar Gala wrote:
> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
> +#ifdef CONFIG_SMP
> +#define SMP_ADJUST_GLOBAL_DBCR0						       \
> +	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT);				       \
> +	lwz	r9,TI_CPU(r9);						       \
> +	slwi	r9,r9,3;						       \
> +	add	r11,r11,r9;
> +#else
> +#define SMP_ADJUST_GLOBAL_DBCR0
> +#endif
> +#define HANDLE_DBCR							       \
> +	/* Check to see if the dbcr0 register is set up to debug.  Use the     \
> +	   internal debug mode bit to do this. */			       \
> +	lwz	r12,THREAD_DBCR0(r12);					       \
> +	andis.	r12,r12,DBCR0_IDM@h;					       \

Can we use assembler macros rather than preprocessor macros to get rid of
the backslashes?

-Scott

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Kumar Gala]

On Apr 29, 2008, at 1:35 PM, Scott Wood wrote:
> On Tue, Apr 29, 2008 at 08:56:56AM -0500, Kumar Gala wrote:
>> +#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
>> +#ifdef CONFIG_SMP
>> +#define SMP_ADJUST_GLOBAL_DBCR0						       \
>> +	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT);				       \
>> +	lwz	r9,TI_CPU(r9);						       \
>> +	slwi	r9,r9,3;						       \
>> +	add	r11,r11,r9;
>> +#else
>> +#define SMP_ADJUST_GLOBAL_DBCR0
>> +#endif
>> +#define HANDLE_DBCR							       \
>> +	/* Check to see if the dbcr0 register is set up to debug.  Use  
>> the     \
>> +	   internal debug mode bit to do this. */			       \
>> +	lwz	r12,THREAD_DBCR0(r12);					       \
>> +	andis.	r12,r12,DBCR0_IDM@h;					       \
>
> Can we use assembler macros rather than preprocessor macros to get  
> rid of
> the backslashes?

what's an assembler macro look like?  I don't believe we use them  
anywhere else.

- k

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Scott Wood]

On Tue, Apr 29, 2008 at 02:36:32PM -0500, Kumar Gala wrote:
> what's an assembler macro look like?

.macro macroname arg1 arg2
	do something with \arg1
	do something with \arg2
.endm

>  I don't believe we use them anywhere else.

arch/powerpc/boot/ps3-hvcall.S uses them, as well as lots of asm code in
other architectures.

-Scott

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Paul Mackerras]

Kumar Gala writes:

> We need to have unique transfer_to_handler paths for each exception level
> that is supported.  We need to use the proper xSRR0/1 depending on which
> exception level the interrupt was from.  The macro conversion lets up
> templatize this code path.

It seems to me that this implies you are assuming that you will never
ever get a synchronous normal interrupt such as a TLB miss while you
are in a critical or machine check handler.

Wouldn't it be better and safer to have the exception prolog for
critical interrupts save SRR0/1 in the stack frame, and have the
prolog for machine checks save SRR0/1 and CSRR0/1 likewise?

Paul.

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Kumar Gala]

On Apr 29, 2008, at 4:28 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> We need to have unique transfer_to_handler paths for each exception  
>> level
>> that is supported.  We need to use the proper xSRR0/1 depending on  
>> which
>> exception level the interrupt was from.  The macro conversion lets up
>> templatize this code path.
>
> It seems to me that this implies you are assuming that you will never
> ever get a synchronous normal interrupt such as a TLB miss while you
> are in a critical or machine check handler.

Grr.. one more thing to fix :)

> Wouldn't it be better and safer to have the exception prolog for
> critical interrupts save SRR0/1 in the stack frame, and have the
> prolog for machine checks save SRR0/1 and CSRR0/1 likewise?

If we do this I guess we can use SRR0/1 regardless of which level we  
came from.

- k

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Paul Mackerras]

Kumar Gala writes:

> > Wouldn't it be better and safer to have the exception prolog for
> > critical interrupts save SRR0/1 in the stack frame, and have the
> > prolog for machine checks save SRR0/1 and CSRR0/1 likewise?
> 
> If we do this I guess we can use SRR0/1 regardless of which level we  
> came from.

That's the idea.  I actually thought the booke exception prologs
already did that, but it seems I'm wrong.

What sort of things do you expect critical and machine-check handlers
to be needing to do?

Paul.

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Benjamin Herrenschmidt]

On Tue, 2008-04-29 at 18:52 -0500, Kumar Gala wrote:
> On Apr 29, 2008, at 4:28 PM, Paul Mackerras wrote:
> > Kumar Gala writes:
> >
> >> We need to have unique transfer_to_handler paths for each exception  
> >> level
> >> that is supported.  We need to use the proper xSRR0/1 depending on  
> >> which
> >> exception level the interrupt was from.  The macro conversion lets up
> >> templatize this code path.
> >
> > It seems to me that this implies you are assuming that you will never
> > ever get a synchronous normal interrupt such as a TLB miss while you
> > are in a critical or machine check handler.
> 
> Grr.. one more thing to fix :)
> 
> > Wouldn't it be better and safer to have the exception prolog for
> > critical interrupts save SRR0/1 in the stack frame, and have the
> > prolog for machine checks save SRR0/1 and CSRR0/1 likewise?
> 
> If we do this I guess we can use SRR0/1 regardless of which level we  
> came from.

Also consider saving/restoring MAS

Ben.

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Kumar Gala]

On Apr 29, 2008, at 10:24 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> Wouldn't it be better and safer to have the exception prolog for
>>> critical interrupts save SRR0/1 in the stack frame, and have the
>>> prolog for machine checks save SRR0/1 and CSRR0/1 likewise?
>>
>> If we do this I guess we can use SRR0/1 regardless of which level we
>> came from.
>
> That's the idea.  I actually thought the booke exception prologs
> already did that, but it seems I'm wrong.
>
> What sort of things do you expect critical and machine-check handlers
> to be needing to do?

It varies on the parts but remember critical level can be anything  
from watchdog, critical input (equivalent of external input, but at  
the critical level), and debug.  So there is a pretty wide set of  
possibility.

- k

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Kumar Gala]

On Apr 30, 2008, at 1:32 AM, Benjamin Herrenschmidt wrote:
>
> On Tue, 2008-04-29 at 18:52 -0500, Kumar Gala wrote:
>> On Apr 29, 2008, at 4:28 PM, Paul Mackerras wrote:
>>> Kumar Gala writes:
>>>
>>>> We need to have unique transfer_to_handler paths for each exception
>>>> level
>>>> that is supported.  We need to use the proper xSRR0/1 depending on
>>>> which
>>>> exception level the interrupt was from.  The macro conversion  
>>>> lets up
>>>> templatize this code path.
>>>
>>> It seems to me that this implies you are assuming that you will  
>>> never
>>> ever get a synchronous normal interrupt such as a TLB miss while you
>>> are in a critical or machine check handler.
>>
>> Grr.. one more thing to fix :)
>>
>>> Wouldn't it be better and safer to have the exception prolog for
>>> critical interrupts save SRR0/1 in the stack frame, and have the
>>> prolog for machine checks save SRR0/1 and CSRR0/1 likewise?
>>
>> If we do this I guess we can use SRR0/1 regardless of which level we
>> came from.
>
> Also consider saving/restoring MAS

got that.  Does 40x/44x have anything similar we need to save/restore?

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Benjamin Herrenschmidt]

On Wed, 2008-04-30 at 03:02 -0500, Kumar Gala wrote:
> got that.  Does 40x/44x have anything similar we need to save/restore?

MMUCR I'd say... look at what our tlbie does there...

Ben.

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Kumar Gala]

On Apr 30, 2008, at 4:59 PM, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-04-30 at 03:02 -0500, Kumar Gala wrote:
>> got that.  Does 40x/44x have anything similar we need to save/ 
>> restore?
>
> MMUCR I'd say... look at what our tlbie does there...

thanks.  Will take a look.  I just plan on overloading MMUCR with MAS0.

- k

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Josh Boyer]

On Wed, 30 Apr 2008 17:04:08 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> On Apr 30, 2008, at 4:59 PM, Benjamin Herrenschmidt wrote:
> >
> > On Wed, 2008-04-30 at 03:02 -0500, Kumar Gala wrote:
> >> got that.  Does 40x/44x have anything similar we need to save/ 
> >> restore?
> >
> > MMUCR I'd say... look at what our tlbie does there...
> 
> thanks.  Will take a look.  I just plan on overloading MMUCR with MAS0.

Erg.  Why?  Please don't do that.  This is common code and MAS0 doesn't
make much sense on 4xx.  It'll be confusing to anyone that isn't aware
of this change.

Can we come up with a generic #define that gets used instead?

josh

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Benjamin Herrenschmidt]

On Wed, 2008-04-30 at 18:45 -0500, Josh Boyer wrote:
> > thanks.  Will take a look.  I just plan on overloading MMUCR with
> MAS0.
> 
> Erg.  Why?  Please don't do that.  This is common code and MAS0
> doesn't
> make much sense on 4xx.  It'll be confusing to anyone that isn't aware
> of this change.

Nah, he meant using the slot for MAS0 in the exception frame structure
as to not have to define two different structures I suppose...

> Can we come up with a generic #define that gets used instead?
> 
> josh

Ben.

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Josh Boyer]

On Thu, 01 May 2008 09:53:22 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> On Wed, 2008-04-30 at 18:45 -0500, Josh Boyer wrote:
> > > thanks.  Will take a look.  I just plan on overloading MMUCR with
> > MAS0.
> > 
> > Erg.  Why?  Please don't do that.  This is common code and MAS0
> > doesn't
> > make much sense on 4xx.  It'll be confusing to anyone that isn't aware
> > of this change.
> 
> Nah, he meant using the slot for MAS0 in the exception frame structure
> as to not have to define two different structures I suppose...

Ah, ok.  Sorry, still playing catch up on email.  I thought we were
talking about a #define.

josh

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Benjamin Herrenschmidt]

On Wed, 2008-04-30 at 19:11 -0500, Josh Boyer wrote:
> 
> > Nah, he meant using the slot for MAS0 in the exception frame
> structure
> > as to not have to define two different structures I suppose...
> 
> Ah, ok.  Sorry, still playing catch up on email.  I thought we were
> talking about a #define.

Heh, now that I think about it ... maybe :-) That would be bad indeed.
Kumar ?

Cheers
Ben.

Re: [PATCH] [POWERPC] convert transfer_to_handler into a macro

[Kumar Gala]

On Apr 30, 2008, at 7:48 PM, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-04-30 at 19:11 -0500, Josh Boyer wrote:
>>
>>> Nah, he meant using the slot for MAS0 in the exception frame
>> structure
>>> as to not have to define two different structures I suppose...
>>
>> Ah, ok.  Sorry, still playing catch up on email.  I thought we were
>> talking about a #define.
>
> Heh, now that I think about it ... maybe :-) That would be bad indeed.
> Kumar ?

I'll alias the slot.  Similiar to how we use _ESR -> for dsisr

Something like this will be added in asm-offset.c:

DEFINE(MMUCR, STACK_INT_FRAME_SIZE+offsetof(struct exception_regs,  
mas0));