linux-toradex.git/arch/powerpc, branch v4.1.21

KVM: PPC: Book3S HV: Sanitize special-purpose register values on guest exit

2016-03-22T15:10:30+00:00

[ Upstream commit ccec44563b18a0ce90e2d4f332784b3cb25c8e9c ]

Thomas Huth discovered that a guest could cause a hard hang of a
host CPU by setting the Instruction Authority Mask Register (IAMR)
to a suitable value.  It turns out that this is because when the
code was added to context-switch the new special-purpose registers
(SPRs) that were added in POWER8, we forgot to add code to ensure
that they were restored to a sane value on guest exit.

This adds code to set those registers where a bad value could
compromise the execution of the host kernel to a suitable neutral
value on guest exit.

Cc: stable@vger.kernel.org # v3.14+
Fixes: b005255e12a3
Reported-by: Thomas Huth 
Reviewed-by: David Gibson 
Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin

powerpc/eeh: Fix build error caused by pci_dn

2016-03-04T15:25:46+00:00

eeh.h could be included when we have following condition. Then we
run into build error as below: (CONFIG_PPC64 && !CONFIG_EEH) ||
(!CONFIG_PPC64 && !CONFIG_EEH)

In file included from arch/powerpc/kernel/of_platform.c:30:0:
./arch/powerpc/include/asm/eeh.h:344:48: error: ‘struct pci_dn’ \
declared inside parameter list [-Werror]
    :
In file included from arch/powerpc/mm/hash_utils_64.c:49:0:
./arch/powerpc/include/asm/eeh.h:344:48: error: ‘struct pci_dn’ \
declared inside parameter list [-Werror]

This fixes the issue by replacing those empty inline functions
with macro so that we don't rely on @pci_dn when CONFIG_EEH is
disabled.

Cc: stable@vger.kernel.org # v4.1+
Fixes: ff57b45 ("powerpc/eeh: Do probe on pci_dn")
Reported-by: Guenter Roeck 
Signed-off-by: Gavin Shan 
Signed-off-by: Sasha Levin

powerpc/eeh: Fix stale cached primary bus

2016-03-04T15:25:43+00:00

[ Upstream commit 05ba75f848647135f063199dc0e9f40fee769724 ]

When PE is created, its primary bus is cached to pe->bus. At later
point, the cached primary bus is returned from eeh_pe_bus_get().
However, we could get stale cached primary bus and run into kernel
crash in one case: full hotplug as part of fenced PHB error recovery
releases all PCI busses under the PHB at unplugging time and recreate
them at plugging time. pe->bus is still dereferencing the PCI bus
that was released.

This adds another PE flag (EEH_PE_PRI_BUS) to represent the validity
of pe->bus. pe->bus is updated when its first child EEH device is
online and the flag is set. Before unplugging in full hotplug for
error recovery, the flag is cleared.

Fixes: 8cdb2833 ("powerpc/eeh: Trace PCI bus from PE")
Cc: stable@vger.kernel.org #v3.11+
Reported-by: Andrew Donnellan 
Reported-by: Pradipta Ghosh 
Signed-off-by: Gavin Shan 
Tested-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin

powerpc/eeh: Fix PE location code

2016-02-15T20:45:23+00:00

[ Upstream commit 7e56f627768da4e6480986b5145dc3422bc448a5 ]

In eeh_pe_loc_get(), the PE location code is retrieved from the
"ibm,loc-code" property of the device node for the bridge of the
PE's primary bus. It's not correct because the property indicates
the parent PE's location code.

This reads the correct PE location code from "ibm,io-base-loc-code"
or "ibm,slot-location-code" property of PE parent bus's device node.

Cc: stable@vger.kernel.org # v3.16+
Fixes: 357b2f3dd9b7 ("powerpc/eeh: Dump PE location code")
Signed-off-by: Gavin Shan 
Tested-by: Russell Currey 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin

KVM: PPC: Fix ONE_REG AltiVec support

2016-02-03T21:23:14+00:00

[ Upstream commit b4d7f161feb3015d6306e1d35b565c888ff70c9d ]

The get and set operations got exchanged by mistake when moving the
code from book3s.c to powerpc.c.

Fixes: 3840edc8033ad5b86deee309c1c321ca54257452
Cc: stable@vger.kernel.org # 3.18+
Signed-off-by: Greg Kurz 
Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin

KVM: PPC: Fix emulation of H_SET_DABR/X on POWER8

2016-02-01T16:37:09+00:00

[ Upstream commit 760a7364f27d974d100118d88190e574626e18a6 ]

In the old DABR register, the BT (Breakpoint Translation) bit
is bit number 61. In the new DAWRX register, the WT (Watchpoint
Translation) bit is bit number 59. So to move the DABR-BT bit
into the position of the DAWRX-WT bit, it has to be shifted by
two, not only by one. This fixes hardware watchpoints in gdb of
older guests that only use the H_SET_DABR/X interface instead
of the new H_SET_MODE interface.

Cc: stable@vger.kernel.org # v3.14+
Signed-off-by: Thomas Huth 
Reviewed-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin

powerpc/module: Handle R_PPC64_ENTRY relocations

2016-01-31T19:23:39+00:00

commit a61674bdfc7c2bf909c4010699607b62b69b7bec upstream.

GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le.  This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:

func:
	addis r2,r12,(.TOC.-func)@ha
	addi  r2,r2,(.TOC.-func)@l
	.localentry func, .-func

To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:

	.quad .TOC.-func
func:
	.reloc ., R_PPC64_ENTRY
	ld    r2, -8(r12)
	add   r2, r2, r12
	.localentry func, .-func

The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.

Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too.  This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.

Signed-off-by: Ulrich Weigand 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered

2016-01-31T19:23:38+00:00

commit 81d7a3294de7e9828310bbf986a67246b13fa01e upstream.

According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_
versions all need to be fully ordered, however they are now just
RELEASE+ACQUIRE, which are not fully ordered.

So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")

This patch depends on patch "powerpc: Make value-returning atomics fully
ordered" for PPC_ATOMIC_ENTRY_BARRIER definition.

Signed-off-by: Boqun Feng 
Reviewed-by: Paul E. McKenney 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc: Make value-returning atomics fully ordered

2016-01-31T19:23:38+00:00

commit 49e9cf3f0c04bf76ffa59242254110309554861d upstream.

According to memory-barriers.txt:

> Any atomic operation that modifies some state in memory and returns
> information about the state (old or new) implies an SMP-conditional
> general memory barrier (smp_mb()) on each side of the actual
> operation ...

Which mean these operations should be fully ordered. However on PPC,
PPC_ATOMIC_ENTRY_BARRIER is the barrier before the actual operation,
which is currently "lwsync" if SMP=y. The leading "lwsync" can not
guarantee fully ordered atomics, according to Paul Mckenney:

https://lkml.org/lkml/2015/10/14/970

To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
the fully-ordered semantics.

This also makes futex atomics fully ordered, which can avoid possible
memory ordering problems if userspace code relies on futex system call
for fully ordered semantics.

Fixes: b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics")
Signed-off-by: Boqun Feng 
Reviewed-by: Paul E. McKenney 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

powerpc/powernv: pr_warn_once on unsupported OPAL_MSG type

2016-01-31T19:23:38+00:00

commit 98da62b716a3b24ab8e77453c9a8a954124c18cd upstream.

When running on newer OPAL firmware that supports sending extra
OPAL_MSG types, we would print a warning on *every* message received.

This could be a problem for kernels that don't support OPAL_MSG_OCC
on machines that are running real close to thermal limits and the
OCC is throttling the chip. For a kernel that is paying attention to
the message queue, we could get these notifications quite often.

Conceivably, future message types could also come fairly often,
and printing that we didn't understand them 10,000 times provides
no further information than printing them once.

Signed-off-by: Stewart Smith 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman