All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dale Farnsworth <dale@farnsworth.org>
Cc: linuxppc-dev@ozlabs.org, Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc
Date: Sat, 05 Apr 2008 09:07:31 +1100	[thread overview]
Message-ID: <1207346851.10388.427.camel@pasglop> (raw)
In-Reply-To: <20080404213932.GA15847@farnsworth.org>


>  config LOCKDEP_SUPPORT
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 69a91bd..bd3ce0f 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -144,6 +144,47 @@ transfer_to_handler:
>  	.globl transfer_to_handler_cont
>  transfer_to_handler_cont:
>  3:
> +#ifdef CONFIG_TRACE_IRQFLAGS
> +	lis	r11,reenable_mmu@h
> +	ori	r11,r11,reenable_mmu@l
> +	mtspr	SPRN_SRR0,r11
> +	mtspr	SPRN_SRR1,r10
> +	SYNC
> +	RFI

I don't think we need that on 4xx/BookE when using AS0 (that is also
true of the existing transfer_to_handler_cont, could be improved there.

> +reenable_mmu:				/* re-enable mmu so we can */
> +	mflr	r9			/* call C code, if necessary */
> +	mfmsr	r10
> +	lwz	r11,_MSR(r1)
> +	xor	r10,r10,r11
> +	andi.	r10,r10,MSR_EE		/* Did EE change? */
> +	beq	1f
> +	stwu	r1,-48(r1)		/* Yes, it must have been cleared */
> +	stw	r9,52(r1)
> +	stw	r0,16(r1)
> +	stw	r3,20(r1)
> +	stw	r4,24(r1)
> +	stw	r5,28(r1)
> +	stw	r6,32(r1)
> +	stw	r7,36(r1)
> +	stw	r8,40(r1)
> +	bl	trace_hardirqs_off
> +	lwz	r0,16(r1)
> +	lwz	r3,20(r1)
> +	lwz	r4,24(r1)
> +	lwz	r5,28(r1)
> +	lwz	r6,32(r1)
> +	lwz	r7,36(r1)
> +	lwz	r8,40(r1)
> +	lwz	r9,52(r1)
> +	addi	r1,r1,48

Why do yo save all the volatile regs ? They should have been saved on
the stack already by the exception prolog (the ptregs on the stack).

Also, only the system call really cares about -restoring- them. Maybe
you could stick that in an ifdef CONFIG_TRACE_IRQFLAGS section in
DoSyscall pulling them back off the ptregs in the stackframe. 

> +	tovirt(r9,r9)
> +	lwz	r11,0(r9)		/* virtual address of handler */
> +	lwz	r9,4(r9)		/* where to go when done */
> +	mtctr	r11
> +	mtlr	r9
> +	bctr				/* jump to handler */
> +#else /* CONFIG_TRACE_IRQFLAGS */
>  	mflr	r9
>  	lwz	r11,0(r9)		/* virtual address of handler */
>  	lwz	r9,4(r9)		/* where to go when done */
> @@ -152,6 +193,7 @@ transfer_to_handler_cont:
>  	mtlr	r9
>  	SYNC
>  	RFI				/* jump to handler, enable MMU */
> +#endif /* CONFIG_TRACE_IRQFLAGS */
>  
>  #ifdef CONFIG_6xx
>  4:	rlwinm	r12,r12,0,~_TLF_NAPPING
> @@ -220,12 +262,20 @@ ret_from_syscall:
>  #ifdef SHOW_SYSCALLS
>  	bl	do_show_syscall_exit
>  #endif
> -	mr	r6,r3
>  	rlwinm	r12,r1,0,0,(31-THREAD_SHIFT)	/* current_thread_info() */
>  	/* disable interrupts so current_thread_info()->flags can't change */
>  	LOAD_MSR_KERNEL(r10,MSR_KERNEL)	/* doesn't include MSR_EE */
>  	SYNC
>  	MTMSRD(r10)
> +#ifdef CONFIG_TRACE_IRQFLAGS
> +	stwu	r1,-16(r1)
> +	stw	r3,12(r1)
> +	bl      trace_hardirqs_off
> +	lwz	r3,12(r1)
> +	addi	r1,r1,16
> +	LOAD_MSR_KERNEL(r10,MSR_KERNEL)
> +#endif

You may get away with pre-storing r3 in RESULT(r1), I'll have to double
check on monday... the 32 bits syscall exit code is a bit scary :-)

I'm pretty sure there's no need to allocate a stackframe. At worst,
there must be some ptregs field in the existing one that can be used.

That's all for today, I'll have another close look on monday.

Cheers,
Ben.

  reply	other threads:[~2008-04-04 22:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-04 21:39 [PATCH v2] powerpc: Add irqtrace support for 32-bit powerpc Dale Farnsworth
2008-04-04 22:07 ` Benjamin Herrenschmidt [this message]
2008-04-04 22:35   ` Dale Farnsworth
2008-04-04 22:46     ` Benjamin Herrenschmidt
2008-04-04 23:31 ` Johannes Berg
2008-04-05  5:14   ` Benjamin Herrenschmidt
2008-04-05  5:41     ` Dale Farnsworth
2008-04-07  4:49 ` Benjamin Herrenschmidt
2008-04-07 13:10   ` Johannes Berg
2008-04-07 16:21     ` Dale Farnsworth
2008-04-07 16:16   ` Dale Farnsworth
2008-04-07 17:14 ` [PATCH v3] " Dale Farnsworth
2008-04-08 16:04   ` Johannes Berg
2008-04-08 21:36     ` Johannes Berg
2008-04-18 13:19       ` Kumar Gala
2008-04-23  4:40       ` Benjamin Herrenschmidt
2008-04-23  6:33         ` Johannes Berg

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=1207346851.10388.427.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=dale@farnsworth.org \
    --cc=johannes@sipsolutions.net \
    --cc=linuxppc-dev@ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.