linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
Date: Thu, 01 May 2008 07:54:55 +1000	[thread overview]
Message-ID: <1209592495.18023.246.camel@pasglop> (raw)
In-Reply-To: <Pine.LNX.4.64.0804300424040.31028@blarg.am.freescale.net>


On Wed, 2008-04-30 at 04:27 -0500, Kumar Gala wrote:
> * Cleanup the code a bit my allocating an INT_FRAME on our exception
>   stack there by make references go from GPR11-INT_FRAME_SIZE(r8) to
>   just GPR(r8)
            ^^ 11 ?

> * simplify {lvl}_transfer_to_handler code by moving the copying of the
>   temp registers we use if we come from user space into the PROLOG
> * If the exception came from kernel mode copy thread_info flags,
>   preempt, and task pointer from the process thread_info.
> 
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> 
> I'm not sure if the copying of TI_FLAGS, TI_PREEMPT, and TI_TASK
> are really needed.  I'm a bit concerned what to do if we get a
> CriticalInput while in kernel mode and the handler causes a reschedule.

Well, reschedule or signal, either way, you can't handle them on the way
out. Maybe an option there is to set the flag in the normal kernel
stack's thread info and trigger an interrupt asap via the PIT so things
get handled ?

> 
> diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
> index d647e05..78baec5 100644
> --- a/arch/powerpc/kernel/head_booke.h
> +++ b/arch/powerpc/kernel/head_booke.h
> @@ -78,12 +78,12 @@
>  	slwi	r8,r8,2;				\
>  	addis	r8,r8,level##_STACK_TOP@ha;		\
>  	lwz	r8,level##_STACK_TOP@l(r8);		\
> -	addi	r8,r8,THREAD_SIZE;
> +	addi	r8,r8,THREAD_SIZE-INT_FRAME_SIZE;
>  #else
>  #define BOOKE_LOAD_EXC_LEVEL_STACK(level)		\
>  	lis	r8,level##_STACK_TOP@ha;		\
>  	lwz	r8,level##_STACK_TOP@l(r8);		\
> -	addi	r8,r8,THREAD_SIZE;
> +	addi	r8,r8,THREAD_SIZE-INT_FRAME_SIZE;
>  #endif

Nothing specific to your patch, but those level##_STACK_TOP seem to
be pretty badly named if you end up -adding- THREAD_SIZE to actually
get to the stack's top. Do they really contain the stack top or do
they in fact contain the stack base/bottom ?

>  /*
> @@ -97,22 +97,35 @@
>  #define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, exc_level_srr1) \
>  	mtspr	exc_level##_SPRG,r8;					     \
>  	BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level stack*/ \
> -	stw	r10,GPR10-INT_FRAME_SIZE(r8);				     \
> -	stw	r11,GPR11-INT_FRAME_SIZE(r8);				     \
> +	stw	r9,GPR9(r8);		/* save various registers	   */\
> +	stw	r10,GPR10(r8);						     \
> +	stw	r11,GPR11(r8);						     \
> +	mfspr	r11,SPRN_SPRG3;		/* if from user, start at top of   */\
> +	lwz	r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
> +	addi	r11,r11,THREAD_SIZE-INT_FRAME_SIZE; /* Alloc exception frm */\

So you do the above whether it will actually be needed or not right ?
 
>  	mfcr	r10;			/* save CR in r10 for now	   */\
> -	mfspr	r11,exc_level_srr1;	/* check whether user or kernel    */\
> -	andi.	r11,r11,MSR_PR;						     \
> -	mr	r11,r8;							     \
> -	mfspr	r8,exc_level##_SPRG;					     \
> +	mfspr	r9,exc_level_srr1;	/* check whether user or kernel    */\
> +	andi.	r9,r9,MSR_PR;						     \
>  	beq	1f;							     \
>  	/* COMING FROM USER MODE */					     \
> -	mfspr	r11,SPRN_SPRG3;		/* if from user, start at top of   */\
> -	lwz	r11,THREAD_INFO-THREAD(r11); /* this thread's kernel stack */\
> -	addi	r11,r11,THREAD_SIZE;					     \
> -1:	subi	r11,r11,INT_FRAME_SIZE;	/* Allocate an exception frame     */\
> +	lwz	r9,GPR9(r8);		/* copy regs from exception stack  */\
> +	stw	r9,GPR9(r11);						     \
> +	lwz	r9,GPR10(r8);						     \
> +	stw	r9,GPR10(r11);						     \
> +	lwz	r9,GPR11(r8);						     \
> +	stw	r9,GPR11(r11);						     \
> +	b	2f;							     \

Are we concerned with performances here or not ? Because using the same
reg all along isn't the best ... 

> +	/* COMING FROM PRIV MODE */					     \
> +1:	lwz	r9,TI_FLAGS-THREAD_SIZE(r11);				     \
> +	stw	r9,TI_FLAGS-THREAD_SIZE(r8);				     \
> +	lwz	r9,TI_PREEMPT-THREAD_SIZE(r11);				     \
> +	stw	r9,TI_PREEMPT-THREAD_SIZE(r8);				     \
> +	lwz	r9,TI_TASK-THREAD_SIZE(r11);				     \
> +	stw	r9,TI_TASK-THREAD_SIZE(r8);				     \
> +	mr	r11,r8;							     \

Don't you want to also stick in HARDIRQ_OFFSET in preempt_count or
leave that to C code ? Also, you might want at one point to tell
lockdep about IRQs being disabled in case they were enabled when
you took the exception. (Do that after you've saved enough
stuff of crouse)

Ben.

  reply	other threads:[~2008-04-30 21:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-30  9:27 [PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code Kumar Gala
2008-04-30 21:54 ` Benjamin Herrenschmidt [this message]
2008-04-30 22:13   ` Kumar Gala
2008-04-30 22:18     ` Benjamin Herrenschmidt
2008-04-30 23:24       ` Kumar Gala
2008-04-30 22:22     ` Benjamin Herrenschmidt
2008-04-30 23:28       ` Kumar Gala
2008-04-30 23:52         ` Benjamin Herrenschmidt
2008-04-30 23:47     ` Paul Mackerras
2008-05-01  6:01       ` Kumar Gala
2008-05-01  7:53         ` Benjamin Herrenschmidt
2008-05-01 13:22           ` Kumar Gala
2008-05-01 14:26             ` Josh Boyer
2008-05-01 14:31               ` Kumar Gala
2008-05-05 11:57             ` Gabriel Paubert
2008-05-05 12:06               ` Benjamin Herrenschmidt
2008-05-01  8:24         ` Paul Mackerras
2008-05-01 13:17           ` Kumar Gala
2008-05-01 16:14             ` Scott Wood
2008-05-01 16:22               ` Scott Wood
2008-05-01 16:33               ` Kumar Gala
2008-05-01 16:42                 ` Scott Wood
2008-05-01 17:48                   ` Kumar Gala
2008-05-01 19:02                     ` Scott Wood
2008-05-01 23:34             ` Paul Mackerras
2008-05-02  4:02               ` Kumar Gala

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=1209592495.18023.246.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=galak@kernel.crashing.org \
    --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).