From: Segher Boessenkool <segher@kernel.crashing.org>
To: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Cc: rusty@rustcorp.com.au, paulus@samba.org, anton@samba.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t
Date: Thu, 27 Nov 2014 10:56:50 -0600 [thread overview]
Message-ID: <20141127165650.GA28278@gate.crashing.org> (raw)
In-Reply-To: <1417090721-25298-2-git-send-email-maddy@linux.vnet.ibm.com>
On Thu, Nov 27, 2014 at 05:48:40PM +0530, Madhavan Srinivasan wrote:
> Here is the design of this patch. Since local_* operations
> are only need to be atomic to interrupts (IIUC), patch uses
> one of the Condition Register (CR) fields as a flag variable. When
> entering the local_*, specific bit in the CR5 field is set
> and on exit, bit is cleared. CR bit checking is done in the
> interrupt return path. If CR5[EQ] bit set and if we return
> to kernel, we reset to start of local_* operation.
Have you tested this with (upcoming) GCC 5.0? GCC now uses CR5,
and it likes to use it very much, it might be more convenient to
use e.g. CR1 (which is allocated almost last, only before CR0).
> --- a/arch/powerpc/include/asm/exception-64s.h
> +++ b/arch/powerpc/include/asm/exception-64s.h
> @@ -306,7 +306,26 @@ do_kvm_##n: \
> std r10,0(r1); /* make stack chain pointer */ \
> std r0,GPR0(r1); /* save r0 in stackframe */ \
> std r10,GPR1(r1); /* save r1 in stackframe */ \
> - beq 4f; /* if from kernel mode */ \
> +BEGIN_FTR_SECTION; \
> + lis r9,4096; /* Create a mask with HV and PR */ \
> + rldicr r9,r9,32,31; /* bits, AND with the MSR */ \
> + mr r10,r9; /* to check for Hyp state */ \
> + ori r9,r9,16384; \
> + and r9,r12,r9; \
> + cmpd cr3,r10,r9; \
> + beq cr3,66f; /* Jump if we come from Hyp mode*/ \
> + mtcrf 0x04,r10; /* Clear CR5 if coming from usr */ \
Wow, such nastiness, only to avoid using dot insns (since you need to keep
the current CR0 value for the following beq 4f). And CR0 already holds the
PR bit, so you need only to check the HV bit anyway? Some restructuring
would make this a lot simpler and clearer.
> + /*
> + * Now that we are about to exit from interrupt, lets check for
> + * cr5 eq bit. If it is set, then we may be in the middle of
> + * local_t update. In this case, we should rewind the NIP
> + * accordingly.
> + */
> + mfcr r3
> + andi. r4,r3,0x200
> + beq 63f
This is just bne cr5,63f isn't it?
> index 72e783e..edb75a9 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -637,7 +637,7 @@ masked_##_H##interrupt: \
> rldicl r10,r10,48,1; /* clear MSR_EE */ \
> rotldi r10,r10,16; \
> mtspr SPRN_##_H##SRR1,r10; \
> -2: mtcrf 0x80,r9; \
> +2: mtcrf 0x90,r9; \
> ld r9,PACA_EXGEN+EX_R9(r13); \
> ld r10,PACA_EXGEN+EX_R10(r13); \
> ld r11,PACA_EXGEN+EX_R11(r13); \
What does this do?
Segher
next prev parent reply other threads:[~2014-11-27 16:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 12:18 [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation Madhavan Srinivasan
2014-11-27 12:18 ` [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t Madhavan Srinivasan
2014-11-27 16:56 ` Segher Boessenkool [this message]
2014-11-28 1:58 ` Benjamin Herrenschmidt
2014-11-28 3:00 ` Madhavan Srinivasan
2014-11-28 15:57 ` Segher Boessenkool
2014-11-28 2:57 ` Madhavan Srinivasan
2014-11-28 16:00 ` Segher Boessenkool
2014-11-28 0:56 ` Benjamin Herrenschmidt
2014-11-28 3:15 ` Madhavan Srinivasan
2014-11-28 3:21 ` Benjamin Herrenschmidt
2014-11-28 10:53 ` David Laight
2014-11-30 9:01 ` Benjamin Herrenschmidt
2014-12-01 21:35 ` Gabriel Paubert
2014-12-03 14:59 ` Madhavan Srinivasan
2014-12-03 17:07 ` Gabriel Paubert
2014-12-02 2:04 ` Scott Wood
2014-12-03 14:49 ` Madhavan Srinivasan
2014-11-27 12:18 ` [RFC PATCH 2/2]powerpc: rewrite local_* to use CR5 flag Madhavan Srinivasan
2014-12-01 18:01 ` Gabriel Paubert
2014-12-03 15:05 ` Madhavan Srinivasan
2014-11-27 14:05 ` [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation David Laight
2014-11-28 8:27 ` Madhavan Srinivasan
2014-11-28 10:09 ` David Laight
2014-12-01 15:35 ` Madhavan Srinivasan
2014-12-01 15:53 ` David Laight
2014-12-18 4:18 ` Rusty Russell
2014-12-18 9:52 ` David Laight
2014-12-18 10:53 ` Rusty Russell
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=20141127165650.GA28278@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=anton@samba.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=rusty@rustcorp.com.au \
/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).