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

[Balbir Singh]

On Sun, Dec 3, 2017 at 1:36 PM, Nicholas Piggin <npiggin at gmail.com> 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