Re: [rfc] powernv/kdump: Fix cases where the kdump kernel can get HMI's

On Sun, Dec 3, 2017 at 1:36 PM, Nicholas Piggin [off-list ref] wrote:

Seems like a reasonable approach. Why do we only do this for
powernv? It seems like a good idea in general to pull all
offlined CPUs out and into the same state for all platforms
and for all shutdown/restart/crash paths.

The reason is largely wake-up related, do we expect offline CPUs to wake
up in the kdump kernel. Largely the infrastructure allows us to selectively
decide what platforms need this support. I did not want to break the world
by enabling it across platforms (pseries for example) without good reason.

Also I wonder if there is anything we should do on the other
side of the equation for the kdump kernel to pull CPUs into a
known state rather than rely on the crash kernel to do it for
us. We might have a better ability to do that with system
reset IPIs now.

Yes, but do we need to do that or quickly dump the vmcore to a file
and exit? Ideally we want the original kernel to wake offline cpus
as appropriate (as we do with kexec) and send them to opal_reinit_cpus
and make them spin on kexec_spin_wait(). The kdump kernel boots
with maxcpus=1 and leaves them spinning

We still need to support platforms without NMI IPIs, so we
still need this patch as well.

True

Thanks for the review!
Balbir Singh