[Skiboot] [PATCH] powerpc/powernv: implement NMI IPI with OPAL_SIGNAL_SYSTEM_RESET

[Nicholas Piggin]

On Fri, 03 Feb 2017 17:00:19 +1100
Alistair Popple <alistair at popple.id.au> wrote:

> On Fri, 3 Feb 2017 03:20:48 PM Nicholas Piggin wrote:
> > On Fri,  3 Feb 2017 00:25:11 +1000
> > Nicholas Piggin <npiggin at gmail.com> wrote:
> >  
> > > This goes with the previous NMI IPI series, and a new version of
> > > Alistair's opal API I posted to the skiboot list.  
> >
> > And here is the incremental bit that is required for Alistair's
> > hardware implementation to work.
> >
> > If the opal broacast call fails with OPAL_PARTIAL, then we designate
> > a bouncer CPU on another core to send NMI IPIs back to our sibling
> > threads.
> >
> > Probably needs more discussion and testing about how to detect and
> > handle failure cases and future compatibility for different types of
> > restrictions, but at least it works in mambo.  
> 
> Looking at the Mambo implementation you recently posted I couldn't see
> where OPAL_PARTIAL was returned. So I guess you have other Skiboot
> patches to test this path using Mambo? I'm wondering because they
> could be useful for testing the skiboot HW side as well...

Oh I just did it all on the Linux side, just forced it to always
do bounce rather than try broadcast first, I was lazy. But we'll
make mambo match the hardware implementation as far as possible
once you've got something.

> > Of course the other option rather than doing this in Linux is call
> > into opal in the system reset handler and have it do the bouncing.
> > Something to consider before we finalise the API.  
> 
> That might not be such a bad idea. OPAL could queue up the threads it
> couldn't reset and then wait until opal_sreset_complete() is called
> from an eligible thread to reset the ones it couldn't do in the
> original call.

Yeah, IIRC we thought it might have been harder to do in firmware,
but that may not be the case.

It may not be a bad idea in general for opal to have a token
available to hook system resets too.

> I might try prototyping something like this when I get some time. One
> issue would be if there is only a single core in the system, but
> that's unlikely and I think that's probably something we can't support
> in any case as cores can't sreset threads on the same core, at least
> on P8.

Yes on powernv it would be unusual, except maybe mambo where we
can make it work.

Thanks,
Nick