[PATCH v3 2/3] powerpc/powernv: Identify scom driven system reset

[Balbir Singh]

On Fri, Dec 15, 2017 at 1:44 PM, Nicholas Piggin <npiggin at gmail.com> wrote:
> On Fri, 15 Dec 2017 12:27:39 +1100
> Balbir Singh <bsingharora at gmail.com> wrote:
>
>> In irq_set_pending_from_srr1() we were missing 0x2 as system
>> reset identified from SRR1 caused by back to back system
>> resets or when interrupts are caused by SCOM when the thread
>> is not in power saving mode.
>>
>> This helps us get to NMI handling in both the case where NMI
>> is caused when in power-saving and not in power-saving mode.
>> The actual exploitation is expected when we are doing a kdump
>> and an offline CPU might not be in power-saving mode due to
>> an already spurious IPI or any other reason.
>>
>> Signed-off-by: Balbir Singh <bsingharora at gmail.com>
>
> When not in power saving mode, we don't look at SRR1 at all, so
> we don't need this. You should never be getting it returned as the
> result of your idle instruction (except on DD1 which has a bug,
> but firmware doesn't implement the NMI IPI).
>

I added this for the next patch. We call irq_set_pending_from_srr1
while coming out of CPU idle, but if for any reason the IPI was spurious
and then we see an NMI during kdump, I did want to detect that
and callback into the NMI handler.

> It's possible we could pay more attention to the reason, for
> example in the powernv system reset handle we might only call
> the NMI IPI handler if it was a scom sreset... but that would
> be a regs->msr test.

regs->msr is the same as SRR1 in my kdump case, but your
right in general we want to look at regs->msr

Balbir Singh