linux.git/arch/powerpc/kernel/exceptions-64e.S, branch v3.14

powerpc: Replaced tlbilx with tlbwe in the initialization code

2014-01-10T23:34:04+00:00

On Freescale e6500 cores EPCR[DGTMI] controls whether guest supervisor
state can execute TLB management instructions. If EPCR[DGTMI]=0
tlbwe and tlbilx are allowed to execute normally in the guest state.

A hypervisor may choose to virtualize TLB1 and for this purpose it
may use IPROT to protect the entries for being invalidated by the
guest. However, because tlbwe and tlbilx execution in the guest state
are sharing the same bit, it is not possible to have a scenario where
tlbwe is allowed to be executed in guest state and tlbilx traps. When
guest TLB management instructions are allowed to be executed in guest
state the guest cannot use tlbilx to invalidate TLB1 guest entries.

Linux is using tlbilx in the boot code to invalidate the temporary
entries it creates when initializing the MMU. The patch is replacing
the usage of tlbilx in initialization code with tlbwe with VALID bit
cleared.

Linux is also using tlbilx in other contexts (like huge pages or
indirect entries) but removing the tlbilx from the initialization code
offers the possibility to have scenarios under hypervisor which are
not using huge pages or indirect entries.

Signed-off-by: Diana Craciun 
Signed-off-by: Scott Wood

powerpc/booke64: Add LRAT error exception handler

2014-01-08T00:15:29+00:00

LRAT (Logical to Real Address Translation) present in MMU v2 provides hardware
translation from a logical page number (LPN) to a real page number (RPN) when
tlbwe is executed by a guest or when a page table translation occurs from a
guest virtual address.

Add LRAT error exception handler to Booke3E 64-bit kernel and the basic KVM
handler to avoid build breakage. This is a prerequisite for KVM LRAT support
that will follow.

Signed-off-by: Mihai Caraman 
Signed-off-by: Scott Wood

powerpc/booke64: Use common defines for AltiVec interrupts numbers

2013-10-16T23:46:40+00:00

On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
common defines to indentify these numbers.

Signed-off-by: Mihai Caraman 
Signed-off-by: Scott Wood

powerpc/booke64: Check napping in performance monitor interrupt

2013-10-11T05:53:09+00:00

The performance monitor interrupt is asynchronous, so we should check
if the current processor is in napping status in the handler of this
interrupt.

Signed-off-by: Kevin Hao 
Signed-off-by: Benjamin Herrenschmidt

powerpc/ppc64: Rename SOFT_DISABLE_INTS with RECONCILE_IRQ_STATE

2013-08-14T04:57:47+00:00

The SOFT_DISABLE_INTS seems an odd name for something that updates the
software state to be consistent with interrupts being hard disabled, so
rename SOFT_DISABLE_INTS with RECONCILE_IRQ_STATE to avoid this confusion.

Signed-off-by: Tiejun Chen 
Signed-off-by: Benjamin Herrenschmidt

powerpc/booke64: Fix kernel hangs at kernel_dbg_exc

2013-05-14T06:00:19+00:00

MSR_DE is not cleared on entry to the kernel, and we don't clear it
explicitly outside of debug code.  If we have MSR_DE set in
prime_debug_regs(), and the new thread has events enabled in DBCR0
(e.g.  ICMP is set in thread->dbsr0, even though it was cleared in the
real DBCR0 when the thread got scheduled out), we'll end up taking a
debug exception in the kernel when DBCR0 is loaded.  DSRR0 will not
point to an exception vector, and the kernel ends up hanging at
kernel_dbg_exc.  Fix this by always clearing MSR_DE when we load new
debug state.

Another observed source of kernel_dbg_exc hangs is with the branch
taken event.  If this event is active, but we take a non-debug trap
(e.g. a TLB miss or an asynchronous interrupt) before the next branch.
We end up taking a branch-taken debug exception on the initial branch
instruction of the exception vector, but because the debug exception is
DBSR_BT rather than DBSR_IC we branch to kernel_dbg_exc before even
checking the DSRR0 address.  Fix this by checking for DBSR_BT as well
as DBSR_IC, which is what 32-bit does and what the comments suggest was
intended in the 64-bit code as well.

Signed-off-by: Scott Wood 
Signed-off-by: Benjamin Herrenschmidt

powerpc/85xx: Add AltiVec support for e6500

2013-03-12T20:59:26+00:00

The e6500 core adds support for AltiVec on a Book-E class processor.
Connect up all the various exception handling code and build config
mechanisms to allow user spaces apps to utilize AltiVec.

Signed-off-by: Kumar Gala

powerpc: Move branch instruction from ACCOUNT_CPU_USER_ENTRY to caller

2013-01-10T06:00:59+00:00

[PATCH 1/6] powerpc: Move branch instruction from ACCOUNT_CPU_USER_ENTRY to caller

The first instruction in ACCOUNT_CPU_USER_ENTRY is 'beq' which checks for
exceptions coming from kernel mode. PPR value will be saved immediately after
ACCOUNT_CPU_USER_ENTRY and is also for user level exceptions. So moved this
branch instruction in the caller code.

Signed-off-by: Haren Myneni 
Signed-off-by: Benjamin Herrenschmidt

powerpc/booke: Separate out restore_e5500/setup_e5500 routines.

2012-09-12T19:57:09+00:00

For the 64 bit case separate out e5500 cpu_setup and cpu_restore functions.
The cpu_setup function (for the primary core) is passed the cpu_spec
pointer, which is not there in case of the cpu_restore function. Also, in
our case we will have to manipulate the CPU_FTR_EMB_HV flag on the primary
core.

Signed-off-by: Varun Sethi 
Signed-off-by: Kumar Gala

powerpc: Restore VDSO information on critical exception om BookE

2012-09-06T23:48:49+00:00

Critical exception on 64-bit booke uses user-visible SPRG3 as scratch.
Restore VDSO information in SPRG3 on exception prolog.

Use a common sprg3 field in PACA for all powerpc64 architectures.

Signed-off-by: Mihai Caraman 
Signed-off-by: Benjamin Herrenschmidt