linux-toradex.git/arch/powerpc/kernel/exceptions-64s.S, branch v3.9.2

powerpc: Fix hardware IRQs with MMU on exceptions when HV=0

2013-05-08T03:33:03+00:00

commit 3e96ca7f007ddb06b82a74a68585d1dbafa85ff1 upstream.

POWER8 allows us to take interrupts with the MMU on.  This gives us a
second set of vectors offset at 0x4000.

Unfortunately when coping these vectors we missed checking for MSR HV
for hardware interrupts (0x500).  This results in us trying to use
HSRR0/1 when HV=0, rather than SRR0/1 on HW IRQs

The below fixes this to check CPU_FTR_HVMODE when patching the code at
0x4500.

Also we remove the check for CPU_FTR_ARCH_206 since relocation on IRQs
are only available in arch 2.07 and beyond.

Thanks to benh for helping find this.

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc: make additional room in exception vector area

2013-03-25T06:14:21+00:00

The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
of that region as it doesn't need to be that close to the call sites
(it is a _GLOBAL function)

Fixes this build error:

arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1304: Error: attempt to move .org backwards

Signed-off-by: Chen Gang 
Signed-off-by: Stephen Rothwell

powerpc: Rename USER_ESID_BITS* to ESID_BITS*

2013-03-17T01:45:44+00:00

Now we use ESID_BITS of kernel address to build proto vsid. So rename
USER_ESIT_BITS to ESID_BITS

Acked-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: Benjamin Herrenschmidt 
CC:  [v3.8]

powerpc: Update kernel VSID range

2013-03-17T01:39:06+00:00

This patch change the kernel VSID range so that we limit VSID_BITS to 37.
This enables us to support 64TB with 65 bit VA (37+28). Without this patch
we have boot hangs on platforms that only support 65 bit VA.

With this patch we now have proto vsid generated as below:

We first generate a 37-bit "proto-VSID". Proto-VSIDs are generated
from mmu context id and effective segment id of the address.

For user processes max context id is limited to ((1ul << 19) - 5)
for kernel space, we use the top 4 context ids to map address as below
0x7fffc -  [ 0xc000000000000000 - 0xc0003fffffffffff ]
0x7fffd -  [ 0xd000000000000000 - 0xd0003fffffffffff ]
0x7fffe -  [ 0xe000000000000000 - 0xe0003fffffffffff ]
0x7ffff -  [ 0xf000000000000000 - 0xf0003fffffffffff ]

Acked-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
Tested-by: Geoff Levand 
Signed-off-by: Benjamin Herrenschmidt 
CC:  [v3.8]

powerpc: Avoid link stack corruption in MMU on syscall entry path

2013-03-05T05:56:28+00:00

Currently we use the link register to branch up high in the early MMU on
syscall entry path.  Unfortunately, this trashes the link stack as the
address we are going to is not associated with the earlier mflr.

This patch simply converts us to used the count register (volatile over
syscalls anyway) instead.  This is much better at predicting in this
scenario and doesn't trash link stack causing a bunch of additional
branch mispredicts later.  Benchmarking this on POWER8 saves a bunch of
cycles on Anton's null syscall benchmark here:
   http://ozlabs.org/~anton/junkcode/null_syscall.c

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Hook in new transactional memory code

2013-02-15T06:02:23+00:00

This hooks the new transactional memory code into context switching, FP/VMX/VMX
unavailable and exception return.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Add transactional memory unavaliable execption handler

2013-02-15T06:02:22+00:00

These should never happen since we always turn on MSR TM when in userspace. We
don't do lazy TM.

Hence if we hit this, we barf and kill the task as something's gone horribly
wrong.

Signed-off-by: Matt Evans 
Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Save CFAR before branching in interrupt entry paths

2013-02-15T05:54:30+00:00

Some of the interrupt vectors on 64-bit POWER server processors are
only 32 bytes long, which is not enough for the full first-level
interrupt handler.  For these we currently just have a branch to an
out-of-line handler.  However, this means that we corrupt the CFAR
(come-from address register) on POWER7 and later processors.

To fix this, we split the EXCEPTION_PROLOG_1 macro into two pieces:
EXCEPTION_PROLOG_0 contains the part up to the point where the CFAR
is saved in the PACA, and EXCEPTION_PROLOG_1 contains the rest.  We
then put EXCEPTION_PROLOG_0 in the short interrupt vectors before
we branch to the out-of-line handler, which contains the rest of the
first-level interrupt handler.  To facilitate this, we define new
_OOL (out of line) variants of STD_EXCEPTION_PSERIES, etc.

In order to get EXCEPTION_PROLOG_0 to be short enough, i.e., no more
than 6 instructions, it was necessary to move the stores that move
the PPR and CFAR values into the PACA into __EXCEPTION_PROLOG_1 and
to get rid of one of the two HMT_MEDIUM instructions.  Previously
there was a HMT_MEDIUM_PPR_DISCARD before the prolog, which was
nop'd out on processors with the PPR (POWER7 and later), and then
another HMT_MEDIUM inside the HMT_MEDIUM_PPR_SAVE macro call inside
__EXCEPTION_PROLOG_1, which was nop'd out on processors without PPR.
Now the HMT_MEDIUM inside EXCEPTION_PROLOG_0 is there unconditionally
and the HMT_MEDIUM_PPR_DISCARD is not strictly necessary, although
this leaves it in for the interrupt vectors where there is room for
it.

Previously we had a handler for hypervisor maintenance interrupts at
0xe50, which doesn't leave enough room for the vector for hypervisor
emulation assist interrupts at 0xe40, since we need 8 instructions.
The 0xe50 vector was only used on POWER6, as the HMI vector was moved
to 0xe60 on POWER7.  Since we don't support running in hypervisor mode
on POWER6, we just remove the handler at 0xe50.

This also changes denorm_exception_hv to use EXCEPTION_PROLOG_0
instead of open-coding it, and removes the HMT_MEDIUM_PPR_DISCARD
from the relocation-on vectors (since any CPU that supports
relocation-on interrupts also has the PPR).

Signed-off-by: Paul Mackerras 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Remove Cell-specific relocation-on interrupt vector code

2013-02-15T05:54:22+00:00

The Cell processor doesn't support relocation-on interrupts, so we
don't need relocation-on versions of the interrupt vectors that are
purely Cell-specific.  This removes them.

Signed-off-by: Paul Mackerras 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Make room in exception vector area

2013-01-10T06:44:19+00:00

The FWNMI region is fixed at 0x7000 and the vector are now
overflowing that with some configurations. Fix that by moving
some hash management code out of that region as it doesn't need
to be that close to the call sites (isn't accessed using
conditional branches).

Signed-off-by: Benjamin Herrenschmidt