linux-stable.git/arch/powerpc/kernel/setup_64.c, branch v4.19.78

powerpc/speculation: Support 'mitigations=' cmdline option

2019-05-14T17:17:59+00:00

commit 782e69efb3dfed6e8360bc612e8c7827a901a8f9 upstream

Configure powerpc CPU runtime speculation bug mitigations in accordance
with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
v1, Spectre v2, and Speculative Store Bypass.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf 
Signed-off-by: Thomas Gleixner 
Tested-by: Jiri Kosina  (on x86)
Reviewed-by: Jiri Kosina 
Cc: Borislav Petkov 
Cc: "H . Peter Anvin" 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Jiri Kosina 
Cc: Waiman Long 
Cc: Andrea Arcangeli 
Cc: Jon Masters 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: linux-s390@vger.kernel.org
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: Tyler Hicks 
Cc: Linus Torvalds 
Cc: Randy Dunlap 
Cc: Steven Price 
Cc: Phil Auld 
Link: https://lkml.kernel.org/r/245a606e1a42a558a310220312d9b6adb9159df6.1555085500.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman

powerpc/tm: Fix HFSCR bit for no suspend case

2018-11-13T19:08:50+00:00

commit dd9a8c5a87395b6f05552c3b44e42fdc95760552 upstream.

Currently on P9N DD2.1 we end up taking infinite TM facility
unavailable exceptions on the first TM usage by userspace.

In the special case of TM no suspend (P9N DD2.1), Linux is told TM is
off via CPU dt-ftrs but told to (partially) use it via
OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED. So HFSCR[TM] will be off from
dt-ftrs but we need to turn it on for the no suspend case.

This patch fixes this by enabling HFSCR TM in this case.

Cc: stable@vger.kernel.org # 4.15+
Signed-off-by: Michael Neuling 
Signed-off-by: Paul Mackerras 
Signed-off-by: Greg Kroah-Hartman

powerpc: clean inclusions of asm/feature-fixups.h

2018-07-30T12:48:17+00:00

files not using feature fixup don't need asm/feature-fixups.h
files using feature fixup need asm/feature-fixups.h

Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman

powerpc/64: hard disable irqs in panic_smp_self_stop

2018-06-19T11:28:22+00:00

Similarly to commit 855bfe0de1 ("powerpc: hard disable irqs in
smp_send_stop loop"), irqs should be hard disabled by
panic_smp_self_stop.

Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman

powerpc64/ftrace: Delay enabling ftrace on secondary cpus

2018-05-03T12:32:26+00:00

On the boot cpu, though we enable paca->ftrace_enabled in early_setup()
(via cpu_ready_for_interrupts()), we don't start tracing until much
later since ftrace is not initialized yet and since we only support
DYNAMIC_FTRACE on powerpc. However, it is possible that ftrace has been
initialized by the time some of the secondary cpus start up. In this
case, we will try to trace some of the early boot code which can cause
problems.

To address this, move setting paca->ftrace_enabled from
cpu_ready_for_interrupts() to early_setup() for the boot cpu, and towards
the end of start_secondary() for secondary cpus.

Signed-off-by: Naveen N. Rao 
Signed-off-by: Michael Ellerman

powerpc64/ftrace: Add a field in paca to disable ftrace in unsafe code paths

2018-05-03T12:32:25+00:00

We have some C code that we call into from real mode where we cannot
take any exceptions. Though the C functions themselves are mostly safe,
if these functions are traced, there is a possibility that we may take
an exception. For instance, in certain conditions, the ftrace code uses
WARN(), which uses a 'trap' to do its job.

For such scenarios, introduce a new field in paca 'ftrace_enabled',
which is checked on ftrace entry before continuing. This field can then
be set to zero to disable/pause ftrace, and set to a non-zero value to
resume ftrace.

Signed-off-by: Naveen N. Rao 
Signed-off-by: Michael Ellerman

powerpc/64s: Default l1d_size to 64K in RFI fallback flush

2018-04-17T09:29:04+00:00

If there is no d-cache-size property in the device tree, l1d_size could
be zero. We don't actually expect that to happen, it's only been seen
on mambo (simulator) in some configurations.

A zero-size l1d_size leads to the loop in the asm wrapping around to
2^64-1, and then walking off the end of the fallback area and
eventually causing a page fault which is fatal.

Just default to 64K which is correct on some CPUs, and sane enough to
not cause a crash on others.

Fixes: aa8a5e0062ac9 ('powerpc/64s: Add support for RFI flush of L1-D cache')
Signed-off-by: Madhavan Srinivasan 
[mpe: Rewrite comment and change log]
Signed-off-by: Michael Ellerman

powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()

2018-04-10T01:23:10+00:00

The recent LPM changes to setup_rfi_flush() are causing some section
mismatch warnings because we removed the __init annotation on
setup_rfi_flush():

  The function setup_rfi_flush() references
  the function __init ppc64_bolted_size().
  the function __init memblock_alloc_base().

The references are actually in init_fallback_flush(), but that is
inlined into setup_rfi_flush().

These references are safe because:
 - only pseries calls setup_rfi_flush() at runtime
 - pseries always passes L1D_FLUSH_FALLBACK at boot
 - so the fallback flush area will always be allocated
 - so the check in init_fallback_flush() will always return early:
   /* Only allocate the fallback flush area once (at boot time). */
   if (l1d_flush_fallback_area)
   	return;

 - and therefore we won't actually call the freed init routines.

We should rework the code to make it safer by default rather than
relying on the above, but for now as a quick-fix just add a __ref
annotation to squash the warning.

Fixes: abf110f3e1ce ("powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again")
Signed-off-by: Michael Ellerman

Merge branch 'topic/paca' into next

2018-03-30T22:09:36+00:00

Bring in yet another series that touches KVM code, and might need to
be merged into the kvm-ppc branch to resolve conflicts.

This required some changes in pnv_power9_force_smt4_catch/release()
due to the paca array becomming an array of pointers.

powerpc/64: Allocate per-cpu stacks node-local if possible

2018-03-30T13:07:08+00:00

Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman