On Fri, Dec 15, 2017 at 1:44 PM, Nicholas Piggin <npig...@gmail.com> wrote: > On Fri, 15 Dec 2017 12:27:39 +1100 > Balbir Singh <bsinghar...@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 <bsinghar...@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