From: Nicholas Piggin <npiggin@gmail.com> Date: 2017-10-23 08:05:19
I've made this series only avoid the secondary spinloop on powernv.
pSeries is a little bit more complicated, some cases in kexec the
secondaries will be at 0x60. I haven't had time to get all that
sorted out for this merge window, so OPAL-only this time.
Nicholas Piggin (3):
powerpc/powernv: Always stop secondaries before reboot/shutdown
powerpc: use NMI IPI for smp_send_stop
powerpc/powernv: Avoid waiting for secondary hold spinloop with OPAL
arch/powerpc/include/asm/opal.h | 2 +-
arch/powerpc/kernel/head_64.S | 16 +++++++++++-----
arch/powerpc/kernel/setup_64.c | 10 +++++++++-
arch/powerpc/kernel/smp.c | 9 +++++----
arch/powerpc/platforms/powernv/opal-flash.c | 28 +---------------------------
arch/powerpc/platforms/powernv/setup.c | 15 +++++----------
6 files changed, 32 insertions(+), 48 deletions(-)
--
2.13.3
From: Nicholas Piggin <npiggin@gmail.com> Date: 2017-10-23 08:05:22
Currently powernv reboot and shutdown requests just leave secondaries
to do their own things. This is undesirable because they can trigger
any number of watchdogs while waiting for reboot, but also we don't
know what else they might be doing, or they might be stuck somewhere
causing trouble.
The opal scheduled flash update code already ran into watchdog problems
due to flashing taking a long time, but it's possible for regular
reboots to trigger problems too (this is with watchdog_thresh set to 1,
but I have seen it with watchdog_thresh at the default value once too):
reboot: Restarting system
[ 360.038896709,5] OPAL: Reboot request...
Watchdog CPU:0 Hard LOCKUP
Watchdog CPU:44 detected Hard LOCKUP other CPUS:16
Watchdog CPU:16 Hard LOCKUP
watchdog: BUG: soft lockup - CPU#16 stuck for 3s! [swapper/16:0]
So remove the special case for flash update, and unconditionally do
smp_send_stop before rebooting.
Return the CPUs to Linux stop loops rather than OPAL. The reason for
this is that the path to firmware is longer, and the CPUs may have
been interrupted from firmware, which may cause problems to re-enter
it. It's better to put them into a simple spin loop to maximize the
chance of a successful reboot.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/opal.h | 2 +-
arch/powerpc/platforms/powernv/opal-flash.c | 28 +---------------------------
arch/powerpc/platforms/powernv/setup.c | 15 +++++----------
3 files changed, 7 insertions(+), 38 deletions(-)
@@ -303,26 +303,9 @@ static int opal_flash_update(int op)returnrc;}-/* Return CPUs to OPAL before starting FW update */-staticvoidflash_return_cpu(void*info)-{-intcpu=smp_processor_id();--if(!cpu_online(cpu))-return;--/* Disable IRQ */-hard_irq_disable();--/* Return the CPU to OPAL */-opal_return_cpu();-}-/* This gets called just before system reboots */-voidopal_flash_term_callback(void)+voidopal_flash_update_print_message(void){-structcpumaskmask;-if(update_flash_data.status!=FLASH_IMG_READY)return;
@@ -333,15 +316,6 @@ void opal_flash_term_callback(void)/* Small delay to help getting the above message out */msleep(500);--/* Return secondary CPUs to firmware */-cpumask_copy(&mask,cpu_online_mask);-cpumask_clear_cpu(smp_processor_id(),&mask);-if(!cpumask_empty(&mask))-smp_call_function_many(&mask,-flash_return_cpu,NULL,false);-/* Hard disable interrupts */-hard_irq_disable();}/*
From: Nicholas Piggin <npiggin@gmail.com> Date: 2017-10-23 08:05:25
Use the NMI IPI rather than smp_call_function for smp_send_stop.
Have stopped CPUs hard disable interrupts rather than just soft
disable.
This function is used in crash/panic/shutdown paths to bring other
CPUs down as quickly and reliably as possible, and minimizing their
potential to cause trouble.
Avoiding the Linux smp_call_function infrastructure and (if supported)
using true NMI IPIs makes this more robust.
Also use spin loop primitives in the stop callback, mainly to help
processing speed of the active thread speed in the simulator.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/smp.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
From: Nicholas Piggin <npiggin@gmail.com> Date: 2017-10-23 08:05:28
OPAL boot does not insert secondaries at 0x60 to wait at the secondary
hold spinloop. Instead they are started later, and inserted at
generic_secondary_smp_init(), which is after the secondary hold
spinloop.
Avoid waiting on this spinloop when booting with OPAL firmware. This
wait always times out that case.
This saves 100ms boot time on powernv, and 10s of seconds of real time
when booting on the simulator in SMP.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/head_64.S | 16 +++++++++++-----
arch/powerpc/kernel/setup_64.c | 10 +++++++++-
2 files changed, 20 insertions(+), 6 deletions(-)
Good catch, 0day. Thanks.
Rather than have all architectures select NMI_IPI just for this, I
think I'll make it depend on whether NMI_IPI was selected at all.
Otherwise just keep using the normal smp_call_function().
Thanks,
Nick
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-11-10 11:08:35
Nicholas Piggin [off-list ref] writes:
Currently powernv reboot and shutdown requests just leave secondaries
to do their own things. This is undesirable because they can trigger
any number of watchdogs while waiting for reboot, but also we don't
know what else they might be doing, or they might be stuck somewhere
causing trouble.
The opal scheduled flash update code already ran into watchdog problems
due to flashing taking a long time, but it's possible for regular
reboots to trigger problems too (this is with watchdog_thresh set to 1,
but I have seen it with watchdog_thresh at the default value once too):
reboot: Restarting system
[ 360.038896709,5] OPAL: Reboot request...
Watchdog CPU:0 Hard LOCKUP
Watchdog CPU:44 detected Hard LOCKUP other CPUS:16
Watchdog CPU:16 Hard LOCKUP
watchdog: BUG: soft lockup - CPU#16 stuck for 3s! [swapper/16:0]
So remove the special case for flash update, and unconditionally do
smp_send_stop before rebooting.
Return the CPUs to Linux stop loops rather than OPAL. The reason for
this is that the path to firmware is longer, and the CPUs may have
been interrupted from firmware, which may cause problems to re-enter
it. It's better to put them into a simple spin loop to maximize the
chance of a successful reboot.
I always assumed we had to send the CPUs back to OPAL for the flashing
procedure. Is it OK to leave them in Linux?
cheers
From: Nicholas Piggin <npiggin@gmail.com> Date: 2017-11-11 06:00:16
On Fri, 10 Nov 2017 22:08:32 +1100
Michael Ellerman [off-list ref] wrote:
Nicholas Piggin [off-list ref] writes:
quoted
Currently powernv reboot and shutdown requests just leave secondaries
to do their own things. This is undesirable because they can trigger
any number of watchdogs while waiting for reboot, but also we don't
know what else they might be doing, or they might be stuck somewhere
causing trouble.
The opal scheduled flash update code already ran into watchdog problems
due to flashing taking a long time, but it's possible for regular
reboots to trigger problems too (this is with watchdog_thresh set to 1,
but I have seen it with watchdog_thresh at the default value once too):
reboot: Restarting system
[ 360.038896709,5] OPAL: Reboot request...
Watchdog CPU:0 Hard LOCKUP
Watchdog CPU:44 detected Hard LOCKUP other CPUS:16
Watchdog CPU:16 Hard LOCKUP
watchdog: BUG: soft lockup - CPU#16 stuck for 3s! [swapper/16:0]
So remove the special case for flash update, and unconditionally do
smp_send_stop before rebooting.
Return the CPUs to Linux stop loops rather than OPAL. The reason for
this is that the path to firmware is longer, and the CPUs may have
been interrupted from firmware, which may cause problems to re-enter
it. It's better to put them into a simple spin loop to maximize the
chance of a successful reboot.
I always assumed we had to send the CPUs back to OPAL for the flashing
procedure. Is it OK to leave them in Linux?
According to the comment and changelog
2196c6f1ed66eef23df3b478cfe71661ae83726e
It was added just to keep secondaries from going silly. Vasant, can
you remember details?
Thanks,
Nick
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-11-12 11:57:29
Nicholas Piggin [off-list ref] writes:
On Fri, 10 Nov 2017 22:08:32 +1100
Michael Ellerman [off-list ref] wrote:
quoted
Nicholas Piggin [off-list ref] writes:
quoted
Currently powernv reboot and shutdown requests just leave secondaries
to do their own things. This is undesirable because they can trigger
any number of watchdogs while waiting for reboot, but also we don't
know what else they might be doing, or they might be stuck somewhere
causing trouble.
The opal scheduled flash update code already ran into watchdog problems
due to flashing taking a long time, but it's possible for regular
reboots to trigger problems too (this is with watchdog_thresh set to 1,
but I have seen it with watchdog_thresh at the default value once too):
reboot: Restarting system
[ 360.038896709,5] OPAL: Reboot request...
Watchdog CPU:0 Hard LOCKUP
Watchdog CPU:44 detected Hard LOCKUP other CPUS:16
Watchdog CPU:16 Hard LOCKUP
watchdog: BUG: soft lockup - CPU#16 stuck for 3s! [swapper/16:0]
So remove the special case for flash update, and unconditionally do
smp_send_stop before rebooting.
Return the CPUs to Linux stop loops rather than OPAL. The reason for
this is that the path to firmware is longer, and the CPUs may have
been interrupted from firmware, which may cause problems to re-enter
it. It's better to put them into a simple spin loop to maximize the
chance of a successful reboot.
I always assumed we had to send the CPUs back to OPAL for the flashing
procedure. Is it OK to leave them in Linux?
According to the comment and changelog
2196c6f1ed66eef23df3b478cfe71661ae83726e
It was added just to keep secondaries from going silly. Vasant, can
you remember details?
OK. My worry is that we've established an implicit contract with skiboot
on how we do this, and now we're looking to change it.
So I guess we just want to confirm that the skiboot code has not grown a
dependency on us returning CPUs, and then we should probably document
what the expectations are in eg. the OPAL_FLASH_UPDATE docs.
cheers
From: Michael Ellerman <hidden> Date: 2017-11-14 11:12:08
On Mon, 2017-10-23 at 08:05:07 UTC, Nicholas Piggin wrote:
OPAL boot does not insert secondaries at 0x60 to wait at the secondary
hold spinloop. Instead they are started later, and inserted at
generic_secondary_smp_init(), which is after the secondary hold
spinloop.
Avoid waiting on this spinloop when booting with OPAL firmware. This
wait always times out that case.
This saves 100ms boot time on powernv, and 10s of seconds of real time
when booting on the simulator in SMP.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>