On Fri, 15 Dec 2017 13:54:18 +1100 Balbir Singh <bsinghar...@gmail.com> wrote:
> 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. You'll never see it. The SRR1 value you get is the idle wakeup code. So any scom-when-not-idle bit should never be set. Thanks, Nick
