2019-05-27 06:55:01 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2011-09-19 17:44:52 +00:00
|
|
|
/*
|
|
|
|
* SMP support for PowerNV machines.
|
|
|
|
*
|
|
|
|
* Copyright 2011 IBM Corp.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/sched.h>
|
2017-02-08 17:51:36 +00:00
|
|
|
#include <linux/sched/hotplug.h>
|
2011-09-19 17:44:52 +00:00
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/cpu.h>
|
|
|
|
|
|
|
|
#include <asm/irq.h>
|
|
|
|
#include <asm/smp.h>
|
|
|
|
#include <asm/paca.h>
|
|
|
|
#include <asm/machdep.h>
|
|
|
|
#include <asm/cputable.h>
|
|
|
|
#include <asm/firmware.h>
|
|
|
|
#include <asm/vdso_datapage.h>
|
|
|
|
#include <asm/cputhreads.h>
|
|
|
|
#include <asm/xics.h>
|
2017-04-05 07:54:50 +00:00
|
|
|
#include <asm/xive.h>
|
2011-09-19 17:44:57 +00:00
|
|
|
#include <asm/opal.h>
|
2014-04-11 10:31:48 +00:00
|
|
|
#include <asm/runlatch.h>
|
2014-03-11 00:54:06 +00:00
|
|
|
#include <asm/code-patching.h>
|
2014-06-11 05:59:28 +00:00
|
|
|
#include <asm/dbell.h>
|
2015-03-19 08:29:01 +00:00
|
|
|
#include <asm/kvm_ppc.h>
|
|
|
|
#include <asm/ppc-opcode.h>
|
2017-03-22 15:04:14 +00:00
|
|
|
#include <asm/cpuidle.h>
|
2017-12-15 08:14:55 +00:00
|
|
|
#include <asm/kexec.h>
|
|
|
|
#include <asm/reg.h>
|
2019-02-12 00:58:29 +00:00
|
|
|
#include <asm/powernv.h>
|
2011-09-19 17:44:52 +00:00
|
|
|
|
|
|
|
#include "powernv.h"
|
|
|
|
|
2011-09-19 17:44:54 +00:00
|
|
|
#ifdef DEBUG
|
|
|
|
#include <asm/udbg.h>
|
|
|
|
#define DBG(fmt...) udbg_printf(fmt)
|
|
|
|
#else
|
|
|
|
#define DBG(fmt...)
|
|
|
|
#endif
|
|
|
|
|
2013-06-24 19:30:09 +00:00
|
|
|
static void pnv_smp_setup_cpu(int cpu)
|
2011-09-19 17:44:52 +00:00
|
|
|
{
|
2017-09-15 05:25:48 +00:00
|
|
|
/*
|
|
|
|
* P9 workaround for CI vector load (see traps.c),
|
|
|
|
* enable the corresponding HMI interrupt
|
|
|
|
*/
|
|
|
|
if (pvr_version_is(PVR_POWER9))
|
|
|
|
mtspr(SPRN_HMEER, mfspr(SPRN_HMEER) | PPC_BIT(17));
|
|
|
|
|
2017-04-05 07:54:50 +00:00
|
|
|
if (xive_enabled())
|
|
|
|
xive_smp_setup_cpu();
|
|
|
|
else if (cpu != boot_cpuid)
|
2011-09-19 17:44:52 +00:00
|
|
|
xics_setup_cpu();
|
|
|
|
}
|
|
|
|
|
2014-08-19 22:55:18 +00:00
|
|
|
static int pnv_smp_kick_cpu(int nr)
|
2011-09-19 17:44:57 +00:00
|
|
|
{
|
2017-07-04 04:22:46 +00:00
|
|
|
unsigned int pcpu;
|
2014-03-11 00:54:06 +00:00
|
|
|
unsigned long start_here =
|
|
|
|
__pa(ppc_function_entry(generic_secondary_smp_init));
|
2011-09-19 17:44:57 +00:00
|
|
|
long rc;
|
2015-12-09 06:18:20 +00:00
|
|
|
uint8_t status;
|
2011-09-19 17:44:57 +00:00
|
|
|
|
2017-06-27 07:00:06 +00:00
|
|
|
if (nr < 0 || nr >= nr_cpu_ids)
|
2017-06-27 07:00:05 +00:00
|
|
|
return -EINVAL;
|
2011-09-19 17:44:57 +00:00
|
|
|
|
2017-07-04 04:22:46 +00:00
|
|
|
pcpu = get_hard_smp_processor_id(nr);
|
2013-05-14 05:12:31 +00:00
|
|
|
/*
|
2015-12-09 06:18:20 +00:00
|
|
|
* If we already started or OPAL is not supported, we just
|
2013-05-14 05:12:31 +00:00
|
|
|
* kick the CPU via the PACA
|
2011-09-19 17:44:57 +00:00
|
|
|
*/
|
2018-02-13 15:08:12 +00:00
|
|
|
if (paca_ptrs[nr]->cpu_start || !firmware_has_feature(FW_FEATURE_OPAL))
|
2013-05-14 05:12:31 +00:00
|
|
|
goto kick;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point, the CPU can either be spinning on the way in
|
|
|
|
* from kexec or be inside OPAL waiting to be started for the
|
|
|
|
* first time. OPAL v3 allows us to query OPAL to know if it
|
|
|
|
* has the CPUs, so we do that
|
|
|
|
*/
|
2015-12-09 06:18:20 +00:00
|
|
|
rc = opal_query_cpu_status(pcpu, &status);
|
|
|
|
if (rc != OPAL_SUCCESS) {
|
|
|
|
pr_warn("OPAL Error %ld querying CPU %d state\n", rc, nr);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2013-05-14 05:12:31 +00:00
|
|
|
|
2015-12-09 06:18:20 +00:00
|
|
|
/*
|
|
|
|
* Already started, just kick it, probably coming from
|
|
|
|
* kexec and spinning
|
|
|
|
*/
|
|
|
|
if (status == OPAL_THREAD_STARTED)
|
|
|
|
goto kick;
|
2013-05-14 05:12:31 +00:00
|
|
|
|
2015-12-09 06:18:20 +00:00
|
|
|
/*
|
|
|
|
* Available/inactive, let's kick it
|
|
|
|
*/
|
|
|
|
if (status == OPAL_THREAD_INACTIVE) {
|
|
|
|
pr_devel("OPAL: Starting CPU %d (HW 0x%x)...\n", nr, pcpu);
|
|
|
|
rc = opal_start_cpu(pcpu, start_here);
|
|
|
|
if (rc != OPAL_SUCCESS) {
|
|
|
|
pr_warn("OPAL Error %ld starting CPU %d\n", rc, nr);
|
2013-05-14 05:12:31 +00:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/*
|
2015-12-09 06:18:20 +00:00
|
|
|
* An unavailable CPU (or any other unknown status)
|
|
|
|
* shouldn't be started. It should also
|
|
|
|
* not be in the possible map but currently it can
|
|
|
|
* happen
|
2013-05-14 05:12:31 +00:00
|
|
|
*/
|
2015-12-09 06:18:20 +00:00
|
|
|
pr_devel("OPAL: CPU %d (HW 0x%x) is unavailable"
|
|
|
|
" (status %d)...\n", nr, pcpu, status);
|
|
|
|
return -ENODEV;
|
2011-09-19 17:44:57 +00:00
|
|
|
}
|
2015-12-09 06:18:20 +00:00
|
|
|
|
|
|
|
kick:
|
2011-09-19 17:44:57 +00:00
|
|
|
return smp_generic_kick_cpu(nr);
|
|
|
|
}
|
|
|
|
|
2011-09-19 17:44:54 +00:00
|
|
|
#ifdef CONFIG_HOTPLUG_CPU
|
|
|
|
|
|
|
|
static int pnv_smp_cpu_disable(void)
|
|
|
|
{
|
|
|
|
int cpu = smp_processor_id();
|
|
|
|
|
|
|
|
/* This is identical to pSeries... might consolidate by
|
|
|
|
* moving migrate_irqs_away to a ppc_md with default to
|
|
|
|
* the generic fixup_irqs. --BenH.
|
|
|
|
*/
|
|
|
|
set_cpu_online(cpu, false);
|
|
|
|
vdso_data->processorCount--;
|
|
|
|
if (cpu == boot_cpuid)
|
|
|
|
boot_cpuid = cpumask_any(cpu_online_mask);
|
2017-04-05 07:54:50 +00:00
|
|
|
if (xive_enabled())
|
|
|
|
xive_smp_disable_cpu();
|
|
|
|
else
|
|
|
|
xics_migrate_irqs_away();
|
2011-09-19 17:44:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-10-22 11:58:14 +00:00
|
|
|
static void pnv_flush_interrupts(void)
|
|
|
|
{
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_300)) {
|
|
|
|
if (xive_enabled())
|
|
|
|
xive_flush_interrupt();
|
|
|
|
else
|
|
|
|
icp_opal_flush_interrupt();
|
|
|
|
} else {
|
|
|
|
icp_native_flush_interrupt();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-19 17:44:54 +00:00
|
|
|
static void pnv_smp_cpu_kill_self(void)
|
|
|
|
{
|
2019-10-22 11:58:14 +00:00
|
|
|
unsigned long srr1, unexpected_mask, wmask;
|
2011-09-19 17:44:54 +00:00
|
|
|
unsigned int cpu;
|
2019-02-12 00:58:29 +00:00
|
|
|
u64 lpcr_val;
|
2011-09-19 17:44:54 +00:00
|
|
|
|
|
|
|
/* Standard hot unplug procedure */
|
2017-06-13 13:05:46 +00:00
|
|
|
|
2011-09-19 17:44:54 +00:00
|
|
|
idle_task_exit();
|
|
|
|
cpu = smp_processor_id();
|
|
|
|
DBG("CPU%d offline\n", cpu);
|
|
|
|
generic_set_cpu_dead(cpu);
|
|
|
|
smp_wmb();
|
|
|
|
|
2015-03-19 08:29:01 +00:00
|
|
|
wmask = SRR1_WAKEMASK;
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_207S))
|
|
|
|
wmask = SRR1_WAKEMASK_P8;
|
|
|
|
|
2019-10-22 11:58:14 +00:00
|
|
|
/*
|
|
|
|
* This turns the irq soft-disabled state we're called with, into a
|
|
|
|
* hard-disabled state with pending irq_happened interrupts cleared.
|
|
|
|
*
|
|
|
|
* PACA_IRQ_DEC - Decrementer should be ignored.
|
|
|
|
* PACA_IRQ_HMI - Can be ignored, processing is done in real mode.
|
|
|
|
* PACA_IRQ_DBELL, EE, PMI - Unexpected.
|
|
|
|
*/
|
|
|
|
hard_irq_disable();
|
|
|
|
if (generic_check_cpu_restart(cpu))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
unexpected_mask = ~(PACA_IRQ_DEC | PACA_IRQ_HMI | PACA_IRQ_HARD_DIS);
|
|
|
|
if (local_paca->irq_happened & unexpected_mask) {
|
|
|
|
if (local_paca->irq_happened & PACA_IRQ_EE)
|
|
|
|
pnv_flush_interrupts();
|
|
|
|
DBG("CPU%d Unexpected exit while offline irq_happened=%lx!\n",
|
|
|
|
cpu, local_paca->irq_happened);
|
|
|
|
}
|
|
|
|
local_paca->irq_happened = PACA_IRQ_HARD_DIS;
|
|
|
|
|
2019-02-12 00:58:29 +00:00
|
|
|
/*
|
|
|
|
* We don't want to take decrementer interrupts while we are
|
|
|
|
* offline, so clear LPCR:PECE1. We keep PECE2 (and
|
|
|
|
* LPCR_PECE_HVEE on P9) enabled so as to let IPIs in.
|
|
|
|
*
|
|
|
|
* If the CPU gets woken up by a special wakeup, ensure that
|
|
|
|
* the SLW engine sets LPCR with decrementer bit cleared, else
|
|
|
|
* the CPU will come back to the kernel due to a spurious
|
|
|
|
* wakeup.
|
|
|
|
*/
|
|
|
|
lpcr_val = mfspr(SPRN_LPCR) & ~(u64)LPCR_PECE1;
|
|
|
|
pnv_program_cpu_hotplug_lpcr(cpu, lpcr_val);
|
|
|
|
|
2011-09-19 17:44:54 +00:00
|
|
|
while (!generic_check_cpu_restart(cpu)) {
|
powerpc/powernv: Handle irq_happened flag correctly in off-line loop
This fixes a bug where it is possible for an off-line CPU to fail to go
into a low-power state (nap/sleep/winkle), and to become unresponsive to
requests from the KVM subsystem to wake up and run a VCPU. What can
happen is that a maskable interrupt of some kind (external, decrementer,
hypervisor doorbell, or HMI) after we have called local_irq_disable() at
the beginning of pnv_smp_cpu_kill_self() and before interrupts are
hard-disabled inside power7_nap/sleep/winkle(). In this situation, the
pending event is marked in the irq_happened flag in the PACA. This
pending event prevents power7_nap/sleep/winkle from going to the
requested low-power state; instead they return immediately. We don't
deal with any of these pending event flags in the off-line loop in
pnv_smp_cpu_kill_self() because power7_nap et al. return 0 in this case,
so we will have srr1 == 0, and none of the processing to clear
interrupts or doorbells will be done.
Usually, the most obvious symptom of this is that a KVM guest will fail
with a console message saying "KVM: couldn't grab cpu N".
This fixes the problem by making sure we handle the irq_happened flags
properly. First, we hard-disable before the off-line loop. Once we have
hard-disabled, the irq_happened flags can't change underneath us. We
unconditionally clear the DEC and HMI flags: there is no processing of
timer interrupts while off-line, and the necessary HMI processing is all
done in lower-level code. We leave the EE and DBELL flags alone for the
first iteration of the loop, so that we won't fail to respond to a
split-core request that came in just before hard-disabling. Within the
loop, we handle external interrupts if the EE bit is set in irq_happened
as well as if the low-power state was interrupted by an external
interrupt. (We don't need to do the msgclr for a pending doorbell in
irq_happened, because doorbells are edge-triggered and don't remain
pending in hardware.) Then we clear both the EE and DBELL flags, and
once clear, they cannot be set again (until this CPU comes online again,
that is).
This also fixes the debug check to not be done when we just ran a KVM
guest or when the sleep didn't happen because of a pending event in
irq_happened.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-10-21 05:06:24 +00:00
|
|
|
/*
|
|
|
|
* Clear IPI flag, since we don't handle IPIs while
|
|
|
|
* offline, except for those when changing micro-threading
|
|
|
|
* mode, which are handled explicitly below, and those
|
|
|
|
* for coming online, which are handled via
|
|
|
|
* generic_check_cpu_restart() calls.
|
|
|
|
*/
|
KVM: PPC: Book3S HV: use smp_mb() when setting/clearing host_ipi flag
On a 2-socket Power9 system with 32 cores/128 threads (SMT4) and 1TB
of memory running the following guest configs:
guest A:
- 224GB of memory
- 56 VCPUs (sockets=1,cores=28,threads=2), where:
VCPUs 0-1 are pinned to CPUs 0-3,
VCPUs 2-3 are pinned to CPUs 4-7,
...
VCPUs 54-55 are pinned to CPUs 108-111
guest B:
- 4GB of memory
- 4 VCPUs (sockets=1,cores=4,threads=1)
with the following workloads (with KSM and THP enabled in all):
guest A:
stress --cpu 40 --io 20 --vm 20 --vm-bytes 512M
guest B:
stress --cpu 4 --io 4 --vm 4 --vm-bytes 512M
host:
stress --cpu 4 --io 4 --vm 2 --vm-bytes 256M
the below soft-lockup traces were observed after an hour or so and
persisted until the host was reset (this was found to be reliably
reproducible for this configuration, for kernels 4.15, 4.18, 5.0,
and 5.3-rc5):
[ 1253.183290] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1253.183319] rcu: 124-....: (5250 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=1941
[ 1256.287426] watchdog: BUG: soft lockup - CPU#105 stuck for 23s! [CPU 52/KVM:19709]
[ 1264.075773] watchdog: BUG: soft lockup - CPU#24 stuck for 23s! [worker:19913]
[ 1264.079769] watchdog: BUG: soft lockup - CPU#31 stuck for 23s! [worker:20331]
[ 1264.095770] watchdog: BUG: soft lockup - CPU#45 stuck for 23s! [worker:20338]
[ 1264.131773] watchdog: BUG: soft lockup - CPU#64 stuck for 23s! [avocado:19525]
[ 1280.408480] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
[ 1316.198012] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1316.198032] rcu: 124-....: (21003 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=8243
[ 1340.411024] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
[ 1379.212609] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1379.212629] rcu: 124-....: (36756 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=14714
[ 1404.413615] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
[ 1442.227095] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1442.227115] rcu: 124-....: (52509 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=21403
[ 1455.111787] INFO: task worker:19907 blocked for more than 120 seconds.
[ 1455.111822] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.111833] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.111884] INFO: task worker:19908 blocked for more than 120 seconds.
[ 1455.111905] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.111925] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.111966] INFO: task worker:20328 blocked for more than 120 seconds.
[ 1455.111986] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.111998] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112048] INFO: task worker:20330 blocked for more than 120 seconds.
[ 1455.112068] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112097] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112138] INFO: task worker:20332 blocked for more than 120 seconds.
[ 1455.112159] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112179] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112210] INFO: task worker:20333 blocked for more than 120 seconds.
[ 1455.112231] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112242] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112282] INFO: task worker:20335 blocked for more than 120 seconds.
[ 1455.112303] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112332] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112372] INFO: task worker:20336 blocked for more than 120 seconds.
[ 1455.112392] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
CPUs 45, 24, and 124 are stuck on spin locks, likely held by
CPUs 105 and 31.
CPUs 105 and 31 are stuck in smp_call_function_many(), waiting on
target CPU 42. For instance:
# CPU 105 registers (via xmon)
R00 = c00000000020b20c R16 = 00007d1bcd800000
R01 = c00000363eaa7970 R17 = 0000000000000001
R02 = c0000000019b3a00 R18 = 000000000000006b
R03 = 000000000000002a R19 = 00007d537d7aecf0
R04 = 000000000000002a R20 = 60000000000000e0
R05 = 000000000000002a R21 = 0801000000000080
R06 = c0002073fb0caa08 R22 = 0000000000000d60
R07 = c0000000019ddd78 R23 = 0000000000000001
R08 = 000000000000002a R24 = c00000000147a700
R09 = 0000000000000001 R25 = c0002073fb0ca908
R10 = c000008ffeb4e660 R26 = 0000000000000000
R11 = c0002073fb0ca900 R27 = c0000000019e2464
R12 = c000000000050790 R28 = c0000000000812b0
R13 = c000207fff623e00 R29 = c0002073fb0ca808
R14 = 00007d1bbee00000 R30 = c0002073fb0ca800
R15 = 00007d1bcd600000 R31 = 0000000000000800
pc = c00000000020b260 smp_call_function_many+0x3d0/0x460
cfar= c00000000020b270 smp_call_function_many+0x3e0/0x460
lr = c00000000020b20c smp_call_function_many+0x37c/0x460
msr = 900000010288b033 cr = 44024824
ctr = c000000000050790 xer = 0000000000000000 trap = 100
CPU 42 is running normally, doing VCPU work:
# CPU 42 stack trace (via xmon)
[link register ] c00800001be17188 kvmppc_book3s_radix_page_fault+0x90/0x2b0 [kvm_hv]
[c000008ed3343820] c000008ed3343850 (unreliable)
[c000008ed33438d0] c00800001be11b6c kvmppc_book3s_hv_page_fault+0x264/0xe30 [kvm_hv]
[c000008ed33439d0] c00800001be0d7b4 kvmppc_vcpu_run_hv+0x8dc/0xb50 [kvm_hv]
[c000008ed3343ae0] c00800001c10891c kvmppc_vcpu_run+0x34/0x48 [kvm]
[c000008ed3343b00] c00800001c10475c kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
[c000008ed3343b90] c00800001c0f5a78 kvm_vcpu_ioctl+0x470/0x7c8 [kvm]
[c000008ed3343d00] c000000000475450 do_vfs_ioctl+0xe0/0xc70
[c000008ed3343db0] c0000000004760e4 ksys_ioctl+0x104/0x120
[c000008ed3343e00] c000000000476128 sys_ioctl+0x28/0x80
[c000008ed3343e20] c00000000000b388 system_call+0x5c/0x70
--- Exception: c00 (System Call) at 00007d545cfd7694
SP (7d53ff7edf50) is in userspace
It was subsequently found that ipi_message[PPC_MSG_CALL_FUNCTION]
was set for CPU 42 by at least 1 of the CPUs waiting in
smp_call_function_many(), but somehow the corresponding
call_single_queue entries were never processed by CPU 42, causing the
callers to spin in csd_lock_wait() indefinitely.
Nick Piggin suggested something similar to the following sequence as
a possible explanation (interleaving of CALL_FUNCTION/RESCHEDULE
IPI messages seems to be most common, but any mix of CALL_FUNCTION and
!CALL_FUNCTION messages could trigger it):
CPU
X: smp_muxed_ipi_set_message():
X: smp_mb()
X: message[RESCHEDULE] = 1
X: doorbell_global_ipi(42):
X: kvmppc_set_host_ipi(42, 1)
X: ppc_msgsnd_sync()/smp_mb()
X: ppc_msgsnd() -> 42
42: doorbell_exception(): // from CPU X
42: ppc_msgsync()
105: smp_muxed_ipi_set_message():
105: smb_mb()
// STORE DEFERRED DUE TO RE-ORDERING
--105: message[CALL_FUNCTION] = 1
| 105: doorbell_global_ipi(42):
| 105: kvmppc_set_host_ipi(42, 1)
| 42: kvmppc_set_host_ipi(42, 0)
| 42: smp_ipi_demux_relaxed()
| 42: // returns to executing guest
| // RE-ORDERED STORE COMPLETES
->105: message[CALL_FUNCTION] = 1
105: ppc_msgsnd_sync()/smp_mb()
105: ppc_msgsnd() -> 42
42: local_paca->kvm_hstate.host_ipi == 0 // IPI ignored
105: // hangs waiting on 42 to process messages/call_single_queue
This can be prevented with an smp_mb() at the beginning of
kvmppc_set_host_ipi(), such that stores to message[<type>] (or other
state indicated by the host_ipi flag) are ordered vs. the store to
to host_ipi.
However, doing so might still allow for the following scenario (not
yet observed):
CPU
X: smp_muxed_ipi_set_message():
X: smp_mb()
X: message[RESCHEDULE] = 1
X: doorbell_global_ipi(42):
X: kvmppc_set_host_ipi(42, 1)
X: ppc_msgsnd_sync()/smp_mb()
X: ppc_msgsnd() -> 42
42: doorbell_exception(): // from CPU X
42: ppc_msgsync()
// STORE DEFERRED DUE TO RE-ORDERING
-- 42: kvmppc_set_host_ipi(42, 0)
| 42: smp_ipi_demux_relaxed()
| 105: smp_muxed_ipi_set_message():
| 105: smb_mb()
| 105: message[CALL_FUNCTION] = 1
| 105: doorbell_global_ipi(42):
| 105: kvmppc_set_host_ipi(42, 1)
| // RE-ORDERED STORE COMPLETES
-> 42: kvmppc_set_host_ipi(42, 0)
42: // returns to executing guest
105: ppc_msgsnd_sync()/smp_mb()
105: ppc_msgsnd() -> 42
42: local_paca->kvm_hstate.host_ipi == 0 // IPI ignored
105: // hangs waiting on 42 to process messages/call_single_queue
Fixing this scenario would require an smp_mb() *after* clearing
host_ipi flag in kvmppc_set_host_ipi() to order the store vs.
subsequent processing of IPI messages.
To handle both cases, this patch splits kvmppc_set_host_ipi() into
separate set/clear functions, where we execute smp_mb() prior to
setting host_ipi flag, and after clearing host_ipi flag. These
functions pair with each other to synchronize the sender and receiver
sides.
With that change in place the above workload ran for 20 hours without
triggering any lock-ups.
Fixes: 755563bc79c7 ("powerpc/powernv: Fixes for hypervisor doorbell handling") # v4.0
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190911223155.16045-1-mdroth@linux.vnet.ibm.com
2019-09-11 22:31:55 +00:00
|
|
|
kvmppc_clear_host_ipi(cpu);
|
2014-12-09 18:56:53 +00:00
|
|
|
|
2017-03-22 15:04:14 +00:00
|
|
|
srr1 = pnv_cpu_offline(cpu);
|
2014-05-23 08:15:30 +00:00
|
|
|
|
2019-10-22 11:58:14 +00:00
|
|
|
WARN_ON_ONCE(!irqs_disabled());
|
2017-06-13 13:05:46 +00:00
|
|
|
WARN_ON(lazy_irq_pending());
|
|
|
|
|
powerpc/powernv: Return to cpu offline loop when finished in KVM guest
When a secondary hardware thread has finished running a KVM guest, we
currently put that thread into nap mode using a nap instruction in
the KVM code. This changes the code so that instead of doing a nap
instruction directly, we instead cause the call to power7_nap() that
put the thread into nap mode to return. The reason for doing this is
to avoid having the KVM code having to know what low-power mode to
put the thread into.
In the case of a secondary thread used to run a KVM guest, the thread
will be offline from the point of view of the host kernel, and the
relevant power7_nap() call is the one in pnv_smp_cpu_disable().
In this case we don't want to clear pending IPIs in the offline loop
in that function, since that might cause us to miss the wakeup for
the next time the thread needs to run a guest. To tell whether or
not to clear the interrupt, we use the SRR1 value returned from
power7_nap(), and check if it indicates an external interrupt. We
arrange that the return from power7_nap() when we have finished running
a guest returns 0, so pending interrupts don't get flushed in that
case.
Note that it is important a secondary thread that has finished
executing in the guest, or that didn't have a guest to run, should
not return to power7_nap's caller while the kvm_hstate.hwthread_req
flag in the PACA is non-zero, because the return from power7_nap
will reenable the MMU, and the MMU might still be in guest context.
In this situation we spin at low priority in real mode waiting for
hwthread_req to become zero.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-12-03 03:48:40 +00:00
|
|
|
/*
|
|
|
|
* If the SRR1 value indicates that we woke up due to
|
|
|
|
* an external interrupt, then clear the interrupt.
|
|
|
|
* We clear the interrupt before checking for the
|
|
|
|
* reason, so as to avoid a race where we wake up for
|
|
|
|
* some other reason, find nothing and clear the interrupt
|
|
|
|
* just as some other cpu is sending us an interrupt.
|
|
|
|
* If we returned from power7_nap as a result of
|
|
|
|
* having finished executing in a KVM guest, then srr1
|
|
|
|
* contains 0.
|
|
|
|
*/
|
powerpc/powernv: Handle irq_happened flag correctly in off-line loop
This fixes a bug where it is possible for an off-line CPU to fail to go
into a low-power state (nap/sleep/winkle), and to become unresponsive to
requests from the KVM subsystem to wake up and run a VCPU. What can
happen is that a maskable interrupt of some kind (external, decrementer,
hypervisor doorbell, or HMI) after we have called local_irq_disable() at
the beginning of pnv_smp_cpu_kill_self() and before interrupts are
hard-disabled inside power7_nap/sleep/winkle(). In this situation, the
pending event is marked in the irq_happened flag in the PACA. This
pending event prevents power7_nap/sleep/winkle from going to the
requested low-power state; instead they return immediately. We don't
deal with any of these pending event flags in the off-line loop in
pnv_smp_cpu_kill_self() because power7_nap et al. return 0 in this case,
so we will have srr1 == 0, and none of the processing to clear
interrupts or doorbells will be done.
Usually, the most obvious symptom of this is that a KVM guest will fail
with a console message saying "KVM: couldn't grab cpu N".
This fixes the problem by making sure we handle the irq_happened flags
properly. First, we hard-disable before the off-line loop. Once we have
hard-disabled, the irq_happened flags can't change underneath us. We
unconditionally clear the DEC and HMI flags: there is no processing of
timer interrupts while off-line, and the necessary HMI processing is all
done in lower-level code. We leave the EE and DBELL flags alone for the
first iteration of the loop, so that we won't fail to respond to a
split-core request that came in just before hard-disabling. Within the
loop, we handle external interrupts if the EE bit is set in irq_happened
as well as if the low-power state was interrupted by an external
interrupt. (We don't need to do the msgclr for a pending doorbell in
irq_happened, because doorbells are edge-triggered and don't remain
pending in hardware.) Then we clear both the EE and DBELL flags, and
once clear, they cannot be set again (until this CPU comes online again,
that is).
This also fixes the debug check to not be done when we just ran a KVM
guest or when the sleep didn't happen because of a pending event in
irq_happened.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-10-21 05:06:24 +00:00
|
|
|
if (((srr1 & wmask) == SRR1_WAKEEE) ||
|
2017-06-13 13:05:46 +00:00
|
|
|
((srr1 & wmask) == SRR1_WAKEHVI)) {
|
2019-10-22 11:58:14 +00:00
|
|
|
pnv_flush_interrupts();
|
2015-03-19 08:29:01 +00:00
|
|
|
} else if ((srr1 & wmask) == SRR1_WAKEHDBELL) {
|
|
|
|
unsigned long msg = PPC_DBELL_TYPE(PPC_DBELL_SERVER);
|
|
|
|
asm volatile(PPC_MSGCLR(%0) : : "r" (msg));
|
2017-12-15 08:14:55 +00:00
|
|
|
} else if ((srr1 & wmask) == SRR1_WAKERESET) {
|
|
|
|
irq_set_pending_from_srr1(srr1);
|
|
|
|
/* Does not return */
|
powerpc/powernv: Return to cpu offline loop when finished in KVM guest
When a secondary hardware thread has finished running a KVM guest, we
currently put that thread into nap mode using a nap instruction in
the KVM code. This changes the code so that instead of doing a nap
instruction directly, we instead cause the call to power7_nap() that
put the thread into nap mode to return. The reason for doing this is
to avoid having the KVM code having to know what low-power mode to
put the thread into.
In the case of a secondary thread used to run a KVM guest, the thread
will be offline from the point of view of the host kernel, and the
relevant power7_nap() call is the one in pnv_smp_cpu_disable().
In this case we don't want to clear pending IPIs in the offline loop
in that function, since that might cause us to miss the wakeup for
the next time the thread needs to run a guest. To tell whether or
not to clear the interrupt, we use the SRR1 value returned from
power7_nap(), and check if it indicates an external interrupt. We
arrange that the return from power7_nap() when we have finished running
a guest returns 0, so pending interrupts don't get flushed in that
case.
Note that it is important a secondary thread that has finished
executing in the guest, or that didn't have a guest to run, should
not return to power7_nap's caller while the kvm_hstate.hwthread_req
flag in the PACA is non-zero, because the return from power7_nap
will reenable the MMU, and the MMU might still be in guest context.
In this situation we spin at low priority in real mode waiting for
hwthread_req to become zero.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-12-03 03:48:40 +00:00
|
|
|
}
|
2017-12-15 08:14:55 +00:00
|
|
|
|
powerpc/powernv: Handle irq_happened flag correctly in off-line loop
This fixes a bug where it is possible for an off-line CPU to fail to go
into a low-power state (nap/sleep/winkle), and to become unresponsive to
requests from the KVM subsystem to wake up and run a VCPU. What can
happen is that a maskable interrupt of some kind (external, decrementer,
hypervisor doorbell, or HMI) after we have called local_irq_disable() at
the beginning of pnv_smp_cpu_kill_self() and before interrupts are
hard-disabled inside power7_nap/sleep/winkle(). In this situation, the
pending event is marked in the irq_happened flag in the PACA. This
pending event prevents power7_nap/sleep/winkle from going to the
requested low-power state; instead they return immediately. We don't
deal with any of these pending event flags in the off-line loop in
pnv_smp_cpu_kill_self() because power7_nap et al. return 0 in this case,
so we will have srr1 == 0, and none of the processing to clear
interrupts or doorbells will be done.
Usually, the most obvious symptom of this is that a KVM guest will fail
with a console message saying "KVM: couldn't grab cpu N".
This fixes the problem by making sure we handle the irq_happened flags
properly. First, we hard-disable before the off-line loop. Once we have
hard-disabled, the irq_happened flags can't change underneath us. We
unconditionally clear the DEC and HMI flags: there is no processing of
timer interrupts while off-line, and the necessary HMI processing is all
done in lower-level code. We leave the EE and DBELL flags alone for the
first iteration of the loop, so that we won't fail to respond to a
split-core request that came in just before hard-disabling. Within the
loop, we handle external interrupts if the EE bit is set in irq_happened
as well as if the low-power state was interrupted by an external
interrupt. (We don't need to do the msgclr for a pending doorbell in
irq_happened, because doorbells are edge-triggered and don't remain
pending in hardware.) Then we clear both the EE and DBELL flags, and
once clear, they cannot be set again (until this CPU comes online again,
that is).
This also fixes the debug check to not be done when we just ran a KVM
guest or when the sleep didn't happen because of a pending event in
irq_happened.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-10-21 05:06:24 +00:00
|
|
|
smp_mb();
|
2014-05-23 08:15:30 +00:00
|
|
|
|
2017-12-15 08:14:55 +00:00
|
|
|
/*
|
|
|
|
* For kdump kernels, we process the ipi and jump to
|
|
|
|
* crash_ipi_callback
|
|
|
|
*/
|
|
|
|
if (kdump_in_progress()) {
|
|
|
|
/*
|
|
|
|
* If we got to this point, we've not used
|
|
|
|
* NMI's, otherwise we would have gone
|
|
|
|
* via the SRR1_WAKERESET path. We are
|
|
|
|
* using regular IPI's for waking up offline
|
|
|
|
* threads.
|
|
|
|
*/
|
|
|
|
struct pt_regs regs;
|
|
|
|
|
|
|
|
ppc_save_regs(®s);
|
|
|
|
crash_ipi_callback(®s);
|
|
|
|
/* Does not return */
|
|
|
|
}
|
|
|
|
|
2014-05-23 08:15:30 +00:00
|
|
|
if (cpu_core_split_required())
|
|
|
|
continue;
|
|
|
|
|
powerpc/powernv: Handle irq_happened flag correctly in off-line loop
This fixes a bug where it is possible for an off-line CPU to fail to go
into a low-power state (nap/sleep/winkle), and to become unresponsive to
requests from the KVM subsystem to wake up and run a VCPU. What can
happen is that a maskable interrupt of some kind (external, decrementer,
hypervisor doorbell, or HMI) after we have called local_irq_disable() at
the beginning of pnv_smp_cpu_kill_self() and before interrupts are
hard-disabled inside power7_nap/sleep/winkle(). In this situation, the
pending event is marked in the irq_happened flag in the PACA. This
pending event prevents power7_nap/sleep/winkle from going to the
requested low-power state; instead they return immediately. We don't
deal with any of these pending event flags in the off-line loop in
pnv_smp_cpu_kill_self() because power7_nap et al. return 0 in this case,
so we will have srr1 == 0, and none of the processing to clear
interrupts or doorbells will be done.
Usually, the most obvious symptom of this is that a KVM guest will fail
with a console message saying "KVM: couldn't grab cpu N".
This fixes the problem by making sure we handle the irq_happened flags
properly. First, we hard-disable before the off-line loop. Once we have
hard-disabled, the irq_happened flags can't change underneath us. We
unconditionally clear the DEC and HMI flags: there is no processing of
timer interrupts while off-line, and the necessary HMI processing is all
done in lower-level code. We leave the EE and DBELL flags alone for the
first iteration of the loop, so that we won't fail to respond to a
split-core request that came in just before hard-disabling. Within the
loop, we handle external interrupts if the EE bit is set in irq_happened
as well as if the low-power state was interrupted by an external
interrupt. (We don't need to do the msgclr for a pending doorbell in
irq_happened, because doorbells are edge-triggered and don't remain
pending in hardware.) Then we clear both the EE and DBELL flags, and
once clear, they cannot be set again (until this CPU comes online again,
that is).
This also fixes the debug check to not be done when we just ran a KVM
guest or when the sleep didn't happen because of a pending event in
irq_happened.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-10-21 05:06:24 +00:00
|
|
|
if (srr1 && !generic_check_cpu_restart(cpu))
|
2017-06-13 13:05:46 +00:00
|
|
|
DBG("CPU%d Unexpected exit while offline srr1=%lx!\n",
|
|
|
|
cpu, srr1);
|
|
|
|
|
2011-09-19 17:44:54 +00:00
|
|
|
}
|
2017-02-07 00:35:31 +00:00
|
|
|
|
2019-02-12 00:58:29 +00:00
|
|
|
/*
|
|
|
|
* Re-enable decrementer interrupts in LPCR.
|
|
|
|
*
|
|
|
|
* Further, we want stop states to be woken up by decrementer
|
|
|
|
* for non-hotplug cases. So program the LPCR via stop api as
|
|
|
|
* well.
|
|
|
|
*/
|
|
|
|
lpcr_val = mfspr(SPRN_LPCR) | (u64)LPCR_PECE1;
|
|
|
|
pnv_program_cpu_hotplug_lpcr(cpu, lpcr_val);
|
2019-10-22 11:58:14 +00:00
|
|
|
out:
|
2011-09-19 17:44:54 +00:00
|
|
|
DBG("CPU%d coming online...\n", cpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_HOTPLUG_CPU */
|
|
|
|
|
2014-12-12 11:37:40 +00:00
|
|
|
static int pnv_cpu_bootable(unsigned int nr)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Starting with POWER8, the subcore logic relies on all threads of a
|
|
|
|
* core being booted so that they can participate in split mode
|
|
|
|
* switches. So on those machines we ignore the smt_enabled_at_boot
|
|
|
|
* setting (smt-enabled on the kernel command line).
|
|
|
|
*/
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_207S))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return smp_generic_cpu_bootable(nr);
|
|
|
|
}
|
|
|
|
|
2017-04-05 07:54:50 +00:00
|
|
|
static int pnv_smp_prepare_cpu(int cpu)
|
|
|
|
{
|
|
|
|
if (xive_enabled())
|
|
|
|
return xive_smp_prepare_cpu(cpu);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-04-26 07:32:38 +00:00
|
|
|
/* Cause IPI as setup by the interrupt controller (xics or xive) */
|
|
|
|
static void (*ic_cause_ipi)(int cpu);
|
|
|
|
|
2017-04-13 10:16:21 +00:00
|
|
|
static void pnv_cause_ipi(int cpu)
|
|
|
|
{
|
|
|
|
if (doorbell_try_core_ipi(cpu))
|
|
|
|
return;
|
|
|
|
|
2017-04-26 07:32:38 +00:00
|
|
|
ic_cause_ipi(cpu);
|
2017-04-13 10:16:21 +00:00
|
|
|
}
|
|
|
|
|
2017-04-05 07:54:50 +00:00
|
|
|
static void __init pnv_smp_probe(void)
|
|
|
|
{
|
|
|
|
if (xive_enabled())
|
|
|
|
xive_smp_probe();
|
|
|
|
else
|
|
|
|
xics_smp_probe();
|
2017-04-13 10:16:21 +00:00
|
|
|
|
2017-04-13 10:16:24 +00:00
|
|
|
if (cpu_has_feature(CPU_FTR_DBELL)) {
|
2017-04-26 07:32:38 +00:00
|
|
|
ic_cause_ipi = smp_ops->cause_ipi;
|
|
|
|
WARN_ON(!ic_cause_ipi);
|
|
|
|
|
2018-07-05 08:47:00 +00:00
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_300))
|
|
|
|
smp_ops->cause_ipi = doorbell_global_ipi;
|
|
|
|
else
|
2017-04-13 10:16:24 +00:00
|
|
|
smp_ops->cause_ipi = pnv_cause_ipi;
|
2017-04-13 10:16:21 +00:00
|
|
|
}
|
2017-04-05 07:54:50 +00:00
|
|
|
}
|
|
|
|
|
2017-09-29 03:29:42 +00:00
|
|
|
static int pnv_system_reset_exception(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
if (smp_handle_nmi_ipi(regs))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pnv_cause_nmi_ipi(int cpu)
|
|
|
|
{
|
|
|
|
int64_t rc;
|
|
|
|
|
|
|
|
if (cpu >= 0) {
|
2018-05-10 12:21:48 +00:00
|
|
|
int h = get_hard_smp_processor_id(cpu);
|
|
|
|
|
|
|
|
if (opal_check_token(OPAL_QUIESCE))
|
|
|
|
opal_quiesce(QUIESCE_HOLD, h);
|
|
|
|
|
|
|
|
rc = opal_signal_system_reset(h);
|
|
|
|
|
|
|
|
if (opal_check_token(OPAL_QUIESCE))
|
|
|
|
opal_quiesce(QUIESCE_RESUME, h);
|
|
|
|
|
2017-09-29 03:29:42 +00:00
|
|
|
if (rc != OPAL_SUCCESS)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
} else if (cpu == NMI_IPI_ALL_OTHERS) {
|
|
|
|
bool success = true;
|
|
|
|
int c;
|
|
|
|
|
2018-05-10 12:21:48 +00:00
|
|
|
if (opal_check_token(OPAL_QUIESCE))
|
|
|
|
opal_quiesce(QUIESCE_HOLD, -1);
|
2017-09-29 03:29:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We do not use broadcasts (yet), because it's not clear
|
|
|
|
* exactly what semantics Linux wants or the firmware should
|
|
|
|
* provide.
|
|
|
|
*/
|
|
|
|
for_each_online_cpu(c) {
|
|
|
|
if (c == smp_processor_id())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
rc = opal_signal_system_reset(
|
|
|
|
get_hard_smp_processor_id(c));
|
|
|
|
if (rc != OPAL_SUCCESS)
|
|
|
|
success = false;
|
|
|
|
}
|
2018-05-10 12:21:48 +00:00
|
|
|
|
|
|
|
if (opal_check_token(OPAL_QUIESCE))
|
|
|
|
opal_quiesce(QUIESCE_RESUME, -1);
|
|
|
|
|
2017-09-29 03:29:42 +00:00
|
|
|
if (success)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Caller will fall back to doorbells, which may pick
|
|
|
|
* up the remainders.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-09-19 17:44:52 +00:00
|
|
|
static struct smp_ops_t pnv_smp_ops = {
|
2017-04-13 10:16:21 +00:00
|
|
|
.message_pass = NULL, /* Use smp_muxed_ipi_message_pass */
|
|
|
|
.cause_ipi = NULL, /* Filled at runtime by pnv_smp_probe() */
|
2016-12-19 18:30:09 +00:00
|
|
|
.cause_nmi_ipi = NULL,
|
2017-04-05 07:54:50 +00:00
|
|
|
.probe = pnv_smp_probe,
|
|
|
|
.prepare_cpu = pnv_smp_prepare_cpu,
|
2011-09-19 17:44:57 +00:00
|
|
|
.kick_cpu = pnv_smp_kick_cpu,
|
2011-09-19 17:44:52 +00:00
|
|
|
.setup_cpu = pnv_smp_setup_cpu,
|
2014-12-12 11:37:40 +00:00
|
|
|
.cpu_bootable = pnv_cpu_bootable,
|
2011-09-19 17:44:54 +00:00
|
|
|
#ifdef CONFIG_HOTPLUG_CPU
|
|
|
|
.cpu_disable = pnv_smp_cpu_disable,
|
|
|
|
.cpu_die = generic_cpu_die,
|
|
|
|
#endif /* CONFIG_HOTPLUG_CPU */
|
2011-09-19 17:44:52 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/* This is called very early during platform setup_arch */
|
|
|
|
void __init pnv_smp_init(void)
|
|
|
|
{
|
2017-09-29 03:29:42 +00:00
|
|
|
if (opal_check_token(OPAL_SIGNAL_SYSTEM_RESET)) {
|
|
|
|
ppc_md.system_reset_exception = pnv_system_reset_exception;
|
|
|
|
pnv_smp_ops.cause_nmi_ipi = pnv_cause_nmi_ipi;
|
|
|
|
}
|
2011-09-19 17:44:52 +00:00
|
|
|
smp_ops = &pnv_smp_ops;
|
|
|
|
|
2011-09-19 17:44:54 +00:00
|
|
|
#ifdef CONFIG_HOTPLUG_CPU
|
|
|
|
ppc_md.cpu_die = pnv_smp_cpu_kill_self;
|
2017-12-15 08:14:55 +00:00
|
|
|
#ifdef CONFIG_KEXEC_CORE
|
|
|
|
crash_wake_offline = 1;
|
|
|
|
#endif
|
2011-09-19 17:44:54 +00:00
|
|
|
#endif
|
2011-09-19 17:44:52 +00:00
|
|
|
}
|