[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140115012121.GA11229@home.buserror.net>
Date: Tue, 14 Jan 2014 19:27:13 -0600
From: Scott Wood <scottwood@...escale.com>
To: Tiejun Chen <tiejun.chen@...driver.com>
CC: <linuxppc-dev@...ts.ozlabs.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [v6,2/5] powerpc/book3e: store crit/mc/dbg exception thread info
On Wed, Oct 23, 2013 at 05:31:22PM +0800, Tiejun Chen wrote:
> We need to store thread info to these exception thread info like something
> we already did for PPC32.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@...driver.com>
>
> ---
> arch/powerpc/kernel/exceptions-64e.S | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index 68d74b4..a55cf62 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -36,6 +36,19 @@
> */
> #define SPECIAL_EXC_FRAME_SIZE INT_FRAME_SIZE
>
> +/* Now we only store something to exception thread info */
Now as opposed to when? Only as opposed to what else?
> +#define EXC_LEVEL_EXCEPTION_PROLOG(type) \
I'd prefer .macro over #define.
> + ld r14,PACAKSAVE(r13); \
> + CURRENT_THREAD_INFO(r14, r14); \
> + CURRENT_THREAD_INFO(r15, r1); \
> + ld r10,TI_FLAGS(r14); \
> + std r10,TI_FLAGS(r15); \
> + ld r10,TI_PREEMPT(r14); \
> + std r10,TI_PREEMPT(r15); \
> + ld r10,TI_TASK(r14); \
> + std r10,TI_TASK(r15);
This is a start, but we'll also need to save some more context to allow
TLB misses from within the exception (e.g. if a machine check handler or
GDB stub writes to a serial port, and the I/O registers aren't in the
TLB). At a minimum I think we need to save SRR0, SRR1,
SPRN_SPRG_GEN_SCRATCH, SPRN_SPRG_TLB_SCRATCH, and the MAS registers.
We'll also need to make the bolted TLB miss handlers capable of pointing
to different extables (though they won't need to auto-advance as the
original TLB miss handlers do -- we would advance SPRN_SPRG_TLB_EXFRAME
from this code), and the original TLB miss handlers will now need to
support more than 3 levels of nesting.
For the e6500 tablewalk TLB miss handler, we'll need to do something
special if we interrupt it when the lock is held, to revoke the lock and
return to code that retries.
Is there anything else I'm missing?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists