On Fri, 03 Feb 2017 17:00:19 +1100 Alistair Popple <alist...@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 <npig...@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