* [PATCH 01/17] powerpc: Add new CPU feature bit for transactional memory
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1360729895-304-1-git-send-email-mikey@neuling.org>
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/cputable.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 5f1938f..3636081 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -220,6 +220,13 @@ extern const char *powerpc_base_platform;
#define PPC_FEATURE_HAS_EFP_DOUBLE_COMP 0
#endif
+/* We only set the TM feature if the kernel was compiled with TM supprt */
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+#define CPU_FTR_TM_COMP CPU_FTR_TM
+#else
+#define CPU_FTR_TM_COMP 0
+#endif
+
/* We need to mark all pages as being coherent if we're SMP or we have a
* 74[45]x and an MPC107 host bridge. Also 83xx and PowerQUICC II
* require it for PCI "streaming/prefetch" to work properly.
--
1.7.10.4
^ permalink raw reply related
* [PATCH 00/17] powerpc: Hardware transactional memory support for POWER8
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1358488117-17363-1-git-send-email-mikey@neuling.org>
POWER8 implements hardware transactional memory support. This patch series
adds kernel support so that user programs can use this hardware transactional
memory and the new state is properly context switched. It is not currently
used by the kernel itself.
This patch series was originally developed by Matt Evans.
v3 changes:
Incorporate review from benh (offline conversation):
- Improve IRQ disabling for tm_reclaim
- Improve IRQ disabling for early fp/vmx/vsx unavail handling
- Change CONFIG option to add PPC (now PPC_TRANSACTIONAL_MEM)
- strip some unneeded #defines
- micro optimisation to asm in early fp/vmx/vsx
- srdi r0, r12, MSR_TS_LG
- andi. r0, r0, 3
+ rldicl. r0, r12, (64-MSR_TS_LG), (64-2)
- do tabort on unmap only when current is using TM
- removed unneeded patch which moved when writing MSR back to the stack
v2 changes:
Adds signal handling
Removes some code for detecting when to restore all register or not
Added tabort for local tlb invalidates
Rebased on benh's next tree
Basic overview of a POWER8 hardware transaction memory
=====================================================
Hardware transactional memory is a feature that enables a different form of
atomic memory access. Several new instructions are presented to delimit
transactions; transactions are guaranteed to either complete atomically or roll
back and undo any partial changes.
A simple transaction looks like this:
begin_move_money:
tbegin
beq abort_handler
ld r4, SAVINGS_ACCT(r3)
ld r5, CURRENT_ACCT(r3)
subi r5, r5, 1
addi r4, r4, 1
std r4, SAVINGS_ACCT(r3)
std r5, CURRENT_ACCT(r3)
tend
b continue
abort_handler:
... test for odd failures ...
/* Retry the transaction if it failed because it conflicted with
* someone else: */
b begin_move_money
The 'tbegin' instruction denotes the start point, and 'tend' the end point.
Between these points the processor is in 'Transactional' state; any memory
references will complete in one go if there are no conflicts with other
transactional or non-transactional accesses within the system. In this
example, the transaction completes as though it were normal straight-line code
IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
atomic move of money from the current account to the savings account has been
performed. Even though the normal ld/std instructions are used (note no
lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
updated, or neither will be updated.
If, in the meantime, there is a conflict with the locations accessed by the
transaction, the transaction will be aborted by the CPU. Register and memory
state will roll back to that at the 'tbegin', and control will continue from
'tbegin+4'. The branch to abort_handler will be taken this second time; the
abort handler can check the cause of the failure, and retry.
Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
and a few other status/flag regs;
A preliminary ISA for TM can be found here:
https://www.power.org/documentation/power-isa-transactional-memory/
--
1.7.10.4
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 4:17 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360718594.24612.21@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 6:53 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Michael Neuling; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, February 13, 2013 12:03 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Michael Neuling; Wood Scott-B07421;
> > linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > > To me this looks wrong. And this seems to works because the
> > > > thread->reg->msr is not actually used to write SRR1 (and
> > eventually
> > > > the thread MSR) when doing rfi to enter guest. Infact
> > > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper
> > MSR
> > > > (including FP set).
> > > >
> > > > But Yes, Scott is right person to comment, So let us wait for him
> > > > comment.
> > >
> > > I don't think it's actually a problem on 32-bit, since r9 is
> > modified but never
> > > actually used for anything.
> >
> > Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and
> > then r9 is written back in srr1 ?
>=20
> What epilog? We're talking about the case where it's called from C code.
>=20
> When it's called from an exception handler, then r9 is used, but in that =
case
> it's also initialized before calling load_up_fpu, by the prolog.
>=20
> > > On 64-bit, though, there's a store to the caller's stack frame
> > > (yuck) which the kvm/booke.h caller is not prepared for.
> >
> > So if caller is using r12 then it can lead to come corruption, right ?
>=20
> No, r12 is a volatile register in the ABI, as is r9. The issue is that t=
he
> stack can be corrupted.
What do you mean by stack is corrupted?
My understanding is that when calling the assembly function from C function=
then stack frame will not be pushed and assembly function uses the caller =
stack frame. Example function1() calls function2() which calls assembly_ro=
utine()
functio1()=20
|---------------------|
| Stack Frame 1 |
| <function1 caller |
| registers etc> |
|---------------------|
Calls function 2
|----------------------|
| Stack Frame 2 |
| <function1 registers |
| etc > |
|----------------------|
| Stack Frame 1 |
| <function1 caller |
| registers etc> |
|----------------------|
calls assembly_routine();
Now no stack frame push; And the assembly_routine() changes register values=
saved in stack. So when stack will be unrolled then registers of function1=
() will get corrupted, right?
Thanks
-Bharat
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Benjamin Herrenschmidt @ 2013-02-13 3:46 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, paulus
In-Reply-To: <87sj50kian.fsf@linux.vnet.ibm.com>
On Wed, 2013-02-13 at 08:54 +0530, Aneesh Kumar K.V wrote:
> > A compile option ? Really ? Ugh...
>
> I actually wanted that to be done in Kconfig.cputype, but haven't found
> a nice way to do it. Considering we are switching between only two
> values, I was thinking an #ifdef would work.
No, we want to support all those processor types from a single kernel image.
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Aneesh Kumar K.V @ 2013-02-13 3:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1360701185.2035.10.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Wed, 2013-02-13 at 00:01 +0530, Aneesh Kumar K.V wrote:
>> + * Be careful with this value. This determines the VSID_MODULUS_* and that
>> + * need to be co-prime with VSID_MULTIPLIER*
>> + */
>> +#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
>> +/*
>> + * Even if cpu support 68 bits, we limit this to 66 because
>> + * we support only 2^19 context.
>> + */
>> +#define MAX_VIRTUAL_ADDR_BITS 66
>> +#else
>> +/* power4,power 5 and cell is 65 */
>> +#define MAX_VIRTUAL_ADDR_BITS 65
>> +#endif
>> +
>
> A compile option ? Really ? Ugh...
I actually wanted that to be done in Kconfig.cputype, but haven't found
a nice way to do it. Considering we are switching between only two
values, I was thinking an #ifdef would work.
-aneesh
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 1:26 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360718594.24612.21@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 6:53 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Michael Neuling; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, February 13, 2013 12:03 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Michael Neuling; Wood Scott-B07421;
> > linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > > To me this looks wrong. And this seems to works because the
> > > > thread->reg->msr is not actually used to write SRR1 (and
> > eventually
> > > > the thread MSR) when doing rfi to enter guest. Infact
> > > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper
> > MSR
> > > > (including FP set).
> > > >
> > > > But Yes, Scott is right person to comment, So let us wait for him
> > > > comment.
> > >
> > > I don't think it's actually a problem on 32-bit, since r9 is
> > modified but never
> > > actually used for anything.
> >
> > Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and
> > then r9 is written back in srr1 ?
>=20
> What epilog? We're talking about the case where it's called from C code
>=20
> When it's called from an exception handler, then r9 is used, but in that =
case
> it's also initialized before calling load_up_fpu, by the prolog.
Agree. Was just confirming the exception handler case.
>=20
> > > On 64-bit, though, there's a store to the caller's stack frame
> > > (yuck) which the kvm/booke.h caller is not prepared for.
> >
> > So if caller is using r12 then it can lead to come corruption, right ?
>=20
> No, r12 is a volatile register in the ABI, as is r9. The issue is that t=
he
> stack can be corrupted.
Ok, Thanks
-Bharat
>=20
> -Scott
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Scott Wood @ 2013-02-13 1:23 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D065A3456@039-SN2MPN1-023.039d.mgd.msft.net>
On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, February 13, 2013 12:03 AM
> > To: Bhushan Bharat-R65777
> > Cc: Michael Neuling; Wood Scott-B07421; =20
> linuxppc-dev@lists.ozlabs.org
> > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> >
> > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > To me this looks wrong. And this seems to works because the
> > > thread->reg->msr is not actually used to write SRR1 (and =20
> eventually
> > > the thread MSR) when doing rfi to enter guest. Infact
> > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper =20
> MSR
> > > (including FP set).
> > >
> > > But Yes, Scott is right person to comment, So let us wait for him
> > > comment.
> >
> > I don't think it's actually a problem on 32-bit, since r9 is =20
> modified but never
> > actually used for anything.
>=20
> Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and =20
> then r9 is written back in srr1 ?
What epilog? We're talking about the case where it's called from C =20
code.
When it's called from an exception handler, then r9 is used, but in =20
that case it's also initialized before calling load_up_fpu, by the =20
prolog.
> > On 64-bit, though, there's a store to the caller's
> > stack frame (yuck) which the kvm/booke.h caller is not prepared for.
>=20
> So if caller is using r12 then it can lead to come corruption, right ?
No, r12 is a volatile register in the ABI, as is r9. The issue is that =20
the stack can be corrupted.
-Scott=
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 1:18 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360693988.24612.4@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 12:03 AM
> To: Bhushan Bharat-R65777
> Cc: Michael Neuling; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > Sent: Tuesday, February 12, 2013 9:46 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > > >
> > > > > Look further down...
> > > > >
> > > > > #ifdef CONFIG_PPC32
> > > > > mfspr r5,SPRN_SPRG_THREAD /* current
> > task's THREAD (phys) */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r9,r9,MSR_FP /* enable FP for
> > current */
> > > > > or r9,r9,r4
> > > > > #else
> > > > > ld r4,PACACURRENT(r13)
> > > > > addi r5,r4,THREAD /* Get THREAD */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r12,r12,MSR_FP
> > > > > or r12,r12,r4
> > > > > std r12,_MSR(r1)
> > > > > #endif
> > > > >
> > > > > R12 is loaded with SRR1 in the exception prolog before
> > load_up_fpu is
> > > called.
> > > >
> > > > Yes it is SRR1 not MSR.
> > >
> > > Yes, SRR1 =3D=3D the MSR of the user process, not the current MSR.
> > >
> > > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> > >
> > > Yep that too.
> > >
> > > So any idea how it's suppose to work or is it broken?
> >
> > To me this looks wrong. And this seems to works because the
> > thread->reg->msr is not actually used to write SRR1 (and eventually
> > the thread MSR) when doing rfi to enter guest. Infact
> > Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR
> > (including FP set).
> >
> > But Yes, Scott is right person to comment, So let us wait for him
> > comment.
>=20
> I don't think it's actually a problem on 32-bit, since r9 is modified but=
never
> actually used for anything.
Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and then r9=
is written back in srr1 ?
> On 64-bit, though, there's a store to the caller's
> stack frame (yuck) which the kvm/booke.h caller is not prepared for.
So if caller is using r12 then it can lead to come corruption, right ?
> Indeed,
> book3s's kvmppc_load_up_fpu creates an interrupt-like stack frame, but do=
es not
> load r9 or r12.
>=20
> It would be really nice if assumptions like these were put in a code comm=
ent
> above load_up_fpu... and if we didn't have so many random differences be=
tween
> 32-bit and 64-bit. :-P
:)
Thanks
-Bharat
>=20
> -Scott
^ permalink raw reply
* [PATCH] powerpc: Apply early paca fixups to boot_paca and the boot cpu's paca
From: Michael Ellerman @ 2013-02-13 0:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: phileas-fogg
In commit 466921c we added a hack to set the paca data_offset to zero so
that per-cpu accesses would work on the boot cpu prior to per-cpu areas
being setup. This fixed a problem with lockdep touching per-cpu areas
very early in boot.
However if we combine CONFIG_LOCK_STAT=y with any of the PPC_EARLY_DEBUG
options, we can hit the same problem in udbg_early_init(). To avoid that
we need to set the data_offset of the boot_paca also. So factor out the
fixup logic and call it for both the boot_paca, and "the paca of the
boot cpu".
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 6da881b..8d97eb4 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -156,6 +156,15 @@ early_param("smt-enabled", early_smt_enabled);
#define check_smt_enabled()
#endif /* CONFIG_SMP */
+/** Fix up paca fields required for the boot cpu */
+static void fixup_boot_paca(void)
+{
+ /* The boot cpu is started */
+ get_paca()->cpu_start = 1;
+ /* Allow percpu accesses to work until we setup percpu data */
+ get_paca()->data_offset = 0;
+}
+
/*
* Early initialization entry point. This is called by head.S
* with MMU translation disabled. We rely on the "feature" of
@@ -185,6 +194,7 @@ void __init early_setup(unsigned long dt_ptr)
/* Assume we're on cpu 0 for now. Don't write to the paca yet! */
initialise_paca(&boot_paca, 0);
setup_paca(&boot_paca);
+ fixup_boot_paca();
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
@@ -205,11 +215,7 @@ void __init early_setup(unsigned long dt_ptr)
/* Now we know the logical id of our boot cpu, setup the paca. */
setup_paca(&paca[boot_cpuid]);
-
- /* Fix up paca fields required for the boot cpu */
- get_paca()->cpu_start = 1;
- /* Allow percpu accesses to "work" until we setup percpu data */
- get_paca()->data_offset = 0;
+ fixup_boot_paca();
/* Probe the machine type */
probe_machine();
--
1.7.10.4
^ permalink raw reply related
* Re: BOOKE KVM calling load_up_fpu from C?
From: Michael Neuling @ 2013-02-12 22:51 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <1360693988.24612.4@snotra>
Scott Wood <scottwood@freescale.com> wrote:
> On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > Sent: Tuesday, February 12, 2013 9:46 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > > >
> > > > > Look further down...
> > > > >
> > > > > #ifdef CONFIG_PPC32
> > > > > mfspr r5,SPRN_SPRG_THREAD /* current
> > task's THREAD (phys) */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r9,r9,MSR_FP /* enable FP for
> > current */
> > > > > or r9,r9,r4
> > > > > #else
> > > > > ld r4,PACACURRENT(r13)
> > > > > addi r5,r4,THREAD /* Get THREAD */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r12,r12,MSR_FP
> > > > > or r12,r12,r4
> > > > > std r12,_MSR(r1)
> > > > > #endif
> > > > >
> > > > > R12 is loaded with SRR1 in the exception prolog before
> > load_up_fpu is
> > > called.
> > > >
> > > > Yes it is SRR1 not MSR.
> > >
> > > Yes, SRR1 == the MSR of the user process, not the current MSR.
> > >
> > > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> > >
> > > Yep that too.
> > >
> > > So any idea how it's suppose to work or is it broken?
> >
> > To me this looks wrong. And this seems to works because the
> > thread->reg->msr is not actually used to write SRR1 (and eventually
> > the thread MSR) when doing rfi to enter guest. Infact
> > Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR
> > (including FP set).
> >
> > But Yes, Scott is right person to comment, So let us wait for him
> > comment.
>
> I don't think it's actually a problem on 32-bit, since r9 is modified
> but never actually used for anything. On 64-bit, though, there's a
> store to the caller's stack frame (yuck) which the kvm/booke.h caller
> is not prepared for. Indeed, book3s's kvmppc_load_up_fpu creates an
> interrupt-like stack frame, but does not load r9 or r12.
Yep.
> It would be really nice if assumptions like these were put in a code
> comment above load_up_fpu... and if we didn't have so many random
> differences between 32-bit and 64-bit. :-P
Yep.. I won't NACK that patch when you send it :-)
It was pretty much assumed that load_up_fpu was going to be called right
after the exception prolog. Calling it any other way was going to be
tricky.
Mikey
^ permalink raw reply
* Re: [PATCH v3] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:16 UTC (permalink / raw)
To: sr; +Cc: netdev, agust, linuxppc-dev
In-Reply-To: <1360674338-12776-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 14:05:38 +0100
> v3:
> - Use of_get_mac_address() instead of of_get_property()
Just to clarify, I applied this version (v3), not v2 (which I
just replied to with "applied").
^ permalink raw reply
* Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:15 UTC (permalink / raw)
To: sr; +Cc: netdev, agust, linuxppc-dev
In-Reply-To: <1360660088-27464-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 10:08:08 +0100
> Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
> (U-Boot) to write the MAC address into the ethernet controller
> registers. The Linux driver should not rely on such a thing. So
> lets read the MAC address from the DT as it should be done here.
>
> The following priority is now used to read the MAC address:
>
> 1) First, try OF node MAC address, if not present or invalid, then:
>
> 2) Read from MAC address registers, if invalid, then:
>
> 3) Log a warning message, and choose a random MAC address.
>
> This fixes a problem with a MPC5200 board that uses the SPL U-Boot
> version without FEC initialization before Linux booting for
> boot speedup.
>
> Additionally a status line is now be printed upon successful
> driver probing, also displaying this MAC address.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Benjamin Herrenschmidt @ 2013-02-12 20:33 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, paulus
In-Reply-To: <1360693905-23503-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Wed, 2013-02-13 at 00:01 +0530, Aneesh Kumar K.V wrote:
> + * Be careful with this value. This determines the VSID_MODULUS_* and that
> + * need to be co-prime with VSID_MULTIPLIER*
> + */
> +#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
> +/*
> + * Even if cpu support 68 bits, we limit this to 66 because
> + * we support only 2^19 context.
> + */
> +#define MAX_VIRTUAL_ADDR_BITS 66
> +#else
> +/* power4,power 5 and cell is 65 */
> +#define MAX_VIRTUAL_ADDR_BITS 65
> +#endif
> +
A compile option ? Really ? Ugh...
Ben.
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/85xx: Board support for ppa8548
From: Kumar Gala @ 2013-02-12 20:09 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, Stef van Os, linuxppc-dev@lists.ozlabs.org,
Paul Mackerras
In-Reply-To: <510FD412.4000505@calxeda.com>
On Feb 4, 2013, at 9:30 AM, Timur Tabi wrote:
> On 02/03/2013 01:39 PM, Stef van Os wrote:
>=20
>> + pci0: pci@fe0008000 {
>> + status =3D "disabled";
>> + };
>> +
>> + pci1: pci@fe0009000 {
>> + status =3D "disabled";
>> + };
>> +
>> + pci2: pcie@fe000a000 {
>> + status =3D "disabled";
>> + };
>=20
> I was hoping you'd follow my example and include a comment indicating =
why the PCI devices are all disabled.
>=20
>> +static void ppa8548_show_cpuinfo(struct seq_file *m)
>> +{
>> + uint svid, phid1;
>=20
> Please don't used unsized integers for hardware registers.
>=20
> uint32_t svid, phid1;
Stef,
If you'd like this included for 3.9, please make the minor updates.
thanks
- k=
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
From: Kumar Gala @ 2013-02-12 20:07 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <1354318502-367-1-git-send-email-kim.phillips@freescale.com>
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote:
> arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not =
declared. Should it be static?
> arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in =
argument 1 (different base types)
> arch/powerpc/sysdev/fsl_msi.c:138:40: expected restricted __be64 =
const [usertype] *p
> arch/powerpc/sysdev/fsl_msi.c:138:40: got unsigned long long const =
[usertype] *[assigned] reg
>=20
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCHv1] crypto: caam - Added property fsl, sec-era in SEC4.0 device tree binding.
From: Kumar Gala @ 2013-02-12 20:04 UTC (permalink / raw)
To: Vakul Garg; +Cc: devicetree-discuss, linuxppc-dev, linux-crypto
In-Reply-To: <1358925668-10330-1-git-send-email-vakul@freescale.com>
On Jan 23, 2013, at 1:21 AM, Vakul Garg wrote:
> This new property defines the era of the particular SEC version.
> The compatible property in device tree "crypto" node has been updated
> not to contain SEC era numbers.
>
> Signed-off-by: Vakul Garg <vakul@freescale.com>
> ---
> Changelog:
> 1. Marked fsl,sec-era as 'optional'.
>
> .../devicetree/bindings/crypto/fsl-sec4.txt | 12 +++++++++---
> 1 files changed, 9 insertions(+), 3 deletions(-)
applied to next.
I assume this supersedes http://patchwork.ozlabs.org/patch/204431/
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
From: Kumar Gala @ 2013-02-12 20:02 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <1354318502-367-1-git-send-email-kim.phillips@freescale.com>
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote:
> arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not =
declared. Should it be static?
> arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in =
argument 1 (different base types)
> arch/powerpc/sysdev/fsl_msi.c:138:40: expected restricted __be64 =
const [usertype] *p
> arch/powerpc/sysdev/fsl_msi.c:138:40: got unsigned long long const =
[usertype] *[assigned] reg
>=20
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCH -next] powerpc/85xx: use for_each_compatible_node() macro
From: Kumar Gala @ 2013-02-12 20:02 UTC (permalink / raw)
To: Wei Yongjun
Cc: devicetree-discuss, linux-kernel, rob.herring, yongjun_wei,
paulus, linuxppc-dev
In-Reply-To: <CAPgLHd_esknTwVv4EeehwSJz6ee5eFJ+zf6xntH-vaNwdxkrvg@mail.gmail.com>
On Dec 3, 2012, at 7:36 AM, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Use for_each_compatible_node() macro instead of open coding it.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: split sbc8548 dts file into pre and post chunks
From: Kumar Gala @ 2013-02-12 20:01 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1358972013-5271-2-git-send-email-paul.gortmaker@windriver.com>
On Jan 23, 2013, at 2:13 PM, Paul Gortmaker wrote:
> Updates to u-boot allow this board to boot off of either
> the 8MB soldered on flash, or the 64MB SODIMM flash.
>=20
> This is achieved by changing JP12 and SW2.8 which in turn
> swaps which flash device appears on /CS0 and /CS6 respectively.
>=20
> Since the flash devices are not the same size, this also
> changes the MTD memory map layout on the local bus.
>=20
> Here we split the common chunks out into a pre and post
> include, so they can be reused by an upcoming "alternative
> boot" dts file; leaving only the local bus chunk behind.
>=20
> No content changes are made at this point - it is just purely
> the move to using include files.
>=20
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/boot/dts/sbc8548-post.dtsi | 295 =
+++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/sbc8548-pre.dtsi | 52 ++++++
> arch/powerpc/boot/dts/sbc8548.dts | 322 =
+-------------------------------
> 3 files changed, 351 insertions(+), 318 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: describe the PAMU topology in the device tree
From: Gala Kumar-B11780 @ 2013-02-12 20:01 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev@ozlabs.org, Wood Scott-B07421, Yoder Stuart-B08248
In-Reply-To: <1358462073-2558-2-git-send-email-timur@tabi.org>
On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> From: Timur Tabi <timur@freescale.com>
>=20
> The PAMU caches use the LIODNs to determine which cache lines hold the
> entries for the corresponding LIODs. The LIODNs must therefore be
> carefully assigned to avoid cache thrashing -- two active LIODs with
> LIODNs that put them in the same cache line.
>=20
> Currently, LIODNs are statically assigned by U-Boot, but this has
> limitations. LIODNs are assigned even for devices that may be disabled
> or unused by the kernel. Static assignments also do not allow for device
> drivers which may know which LIODs can be used simultaneously. In
> other words, we really should assign LIODNs dynamically in Linux.
>=20
> To do that, we need to describe the PAMU device and cache topologies in
> the device trees.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/guts.txt | 14 ++-
> .../devicetree/bindings/powerpc/fsl/pamu.txt | 142 +++++++++++++++=
+++++
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 87 +++++++++++--
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 87 +++++++++++--
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 68 +++++++++-
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 92 +++++++++++--
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 92 +++++++++++--
> 7 files changed, 533 insertions(+), 49 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix various PCI node compatible strings
From: Gala Kumar-B11780 @ 2013-02-12 20:01 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev@ozlabs.org, Wood Scott-B07421, Yoder Stuart-B08248
In-Reply-To: <1358462073-2558-1-git-send-email-timur@tabi.org>
On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> From: Timur Tabi <timur@freescale.com>
>=20
> Fix and/or improve the compatible strings of the PCI device tree nodes fo=
r
> some Freescale SOCs. This fixes some issues and improves consistency amo=
ng
> the SOCs.
>=20
> Specifically:
>=20
> 1) The P1022 has a v1 PCIe controller, so the compatible property should =
just
> say "fsl,mpc8548-pcie". U-Boot does not look for "fsl,p1022-pcie", so it
> wasn't fixing up the node.
>=20
> 2) The P4080 has a v2.1 PCIe controller, so add that version-specific str=
ing
> to the device tree. Update the kernel to also look for that string.
> Currently, the kernel looks for "fsl,p4080-pcie" specifically, but
> eventually that check should be deleted.
>=20
> 3) The P1010 device tree claims compatibility with v2.2 and v2.3, but tha=
t's
> redundant. No other device tree does this. Remove the v2.2 string.
>=20
> 4) The kernel looks for both "fsl,p1023-pcie" and "fsl,qoriq-pcie-v2.2",
> even though the P1023 device trees has always included both strings. Rem=
ove
> the search for "fsl,p1023-pcie".
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 4 ++--
> arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 6 +++---
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 6 +++---
> arch/powerpc/sysdev/fsl_pci.c | 15 ++++++++++-----
> 4 files changed, 18 insertions(+), 13 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/82xx: fix checkpatch warnings for km82xx.c
From: Kumar Gala @ 2013-02-12 20:00 UTC (permalink / raw)
To: Holger Brunck; +Cc: linuxppc-dev
In-Reply-To: <1354892956-14623-1-git-send-email-holger.brunck@keymile.com>
On Dec 7, 2012, at 9:09 AM, Holger Brunck wrote:
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/platforms/82xx/km82xx.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
applied 1-5 to next
- k
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Scott Wood @ 2013-02-12 18:33 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0659EF89@039-SN2MPN1-023.039d.mgd.msft.net>
On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Michael Neuling [mailto:mikey@neuling.org]
> > Sent: Tuesday, February 12, 2013 9:46 AM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> >
> > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > >
> > > > Look further down...
> > > >
> > > > #ifdef CONFIG_PPC32
> > > > mfspr r5,SPRN_SPRG_THREAD /* current =20
> task's THREAD (phys) */
> > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > ori r9,r9,MSR_FP /* enable FP for =20
> current */
> > > > or r9,r9,r4
> > > > #else
> > > > ld r4,PACACURRENT(r13)
> > > > addi r5,r4,THREAD /* Get THREAD */
> > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > ori r12,r12,MSR_FP
> > > > or r12,r12,r4
> > > > std r12,_MSR(r1)
> > > > #endif
> > > >
> > > > R12 is loaded with SRR1 in the exception prolog before =20
> load_up_fpu is
> > called.
> > >
> > > Yes it is SRR1 not MSR.
> >
> > Yes, SRR1 =3D=3D the MSR of the user process, not the current MSR.
> >
> > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> >
> > Yep that too.
> >
> > So any idea how it's suppose to work or is it broken?
>=20
> To me this looks wrong. And this seems to works because the =20
> thread->reg->msr is not actually used to write SRR1 (and eventually =20
> the thread MSR) when doing rfi to enter guest. Infact =20
> Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR =20
> (including FP set).
>=20
> But Yes, Scott is right person to comment, So let us wait for him =20
> comment.
I don't think it's actually a problem on 32-bit, since r9 is modified =20
but never actually used for anything. On 64-bit, though, there's a =20
store to the caller's stack frame (yuck) which the kvm/booke.h caller =20
is not prepared for. Indeed, book3s's kvmppc_load_up_fpu creates an =20
interrupt-like stack frame, but does not load r9 or r12.
It would be really nice if assumptions like these were put in a code =20
comment above load_up_fpu... and if we didn't have so many random =20
differences between 32-bit and 64-bit. :-P
-Scott=
^ permalink raw reply
* Re: [PATCH v5 04/45] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Paul E. McKenney @ 2013-02-12 16:15 UTC (permalink / raw)
To: Oleg Nesterov
Cc: linux-doc, peterz, fweisbec, mingo, linux-arch, linux,
xiaoguangrong, wangyun, nikunj, linux-pm, rusty, rostedt, rjw,
namhyung, tglx, linux-arm-kernel, netdev, linux-kernel, sbw,
Srivatsa S. Bhat, tj, akpm, linuxppc-dev
In-Reply-To: <20130210195417.GK2666@linux.vnet.ibm.com>
On Sun, Feb 10, 2013 at 11:54:17AM -0800, Paul E. McKenney wrote:
> On Sun, Feb 10, 2013 at 07:06:07PM +0100, Oleg Nesterov wrote:
> > On 02/08, Paul E. McKenney wrote:
>
> [ . . . ]
>
> > > > +static inline void sync_reader(struct percpu_rwlock *pcpu_rwlock,
> > > > + unsigned int cpu)
> > > > +{
> > > > + smp_rmb(); /* Paired with smp_[w]mb() in percpu_read_[un]lock() */
> > >
> > > As I understand it, the purpose of this memory barrier is to ensure
> > > that the stores in drop_writer_signal() happen before the reads from
> > > ->reader_refcnt in reader_uses_percpu_refcnt(), thus preventing the
> > > race between a new reader attempting to use the fastpath and this writer
> > > acquiring the lock. Unless I am confused, this must be smp_mb() rather
> > > than smp_rmb().
> >
> > And note that before sync_reader() we call announce_writer_active() which
> > already adds mb() before sync_all_readers/sync_reader, so this rmb() looks
> > unneeded.
> >
> > But, at the same time, could you confirm that we do not need another mb()
> > after sync_all_readers() in percpu_write_lock() ? I mean, without mb(),
> > can't this reader_uses_percpu_refcnt() LOAD leak into the critical section
> > protected by ->global_rwlock? Then this LOAD can be re-ordered with other
> > memory operations done by the writer.
>
> As soon as I get the rest of the way through Thomas's patchset. ;-)
There is a memory barrier associated with write_lock(), but it is
only required to keep the critical section inside the lock -- and is
permitted to allow stuff outside of the lock to be reordered into the
critical section. So I believe we do indeed need an smp_mb() between
sync_all_readers() and write_lock() in percpu_write_lock().
Good eyes, Oleg!
Thanx, Paul
^ permalink raw reply
* [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Aneesh Kumar K.V @ 2013-02-12 18:31 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <1360693905-23503-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Different platforms supports different virtual addr size(n bits). We need to mak sure
0:77-n bits of the VA generated is forced to zero.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/mmu-hash64.h | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
index 5f8c2bd..839efae 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -381,7 +381,27 @@ extern void slb_set_size(u16 size);
* hash collisions.
*/
-#define CONTEXT_BITS 19
+/*
+ * Be careful with this value. This determines the VSID_MODULUS_* and that
+ * need to be co-prime with VSID_MULTIPLIER*
+ */
+#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
+/*
+ * Even if cpu support 68 bits, we limit this to 66 because
+ * we support only 2^19 context.
+ */
+#define MAX_VIRTUAL_ADDR_BITS 66
+#else
+/* power4,power 5 and cell is 65 */
+#define MAX_VIRTUAL_ADDR_BITS 65
+#endif
+
+/*
+ * One bit is taken by the kernel, only the rest of space is available for the
+ * user space.
+ */
+#define CONTEXT_BITS (MAX_VIRTUAL_ADDR_BITS - \
+ (USER_ESID_BITS + SID_SHIFT + 1))
#define USER_ESID_BITS 18
#define USER_ESID_BITS_1T 6
--
1.7.10
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox