[Skiboot] [RFC 1/1] OPAL : Support spr save-restore using new opal call

[Vaidyanathan Srinivasan]

* Nicholas Piggin <npiggin at gmail.com> [2018-07-23 23:41:19]:

> On Mon, 23 Jul 2018 17:14:07 +1000
> Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> 
> > On Mon, 2018-07-23 at 15:30 +1000, Nicholas Piggin wrote:
> > > I'm hoping rather than a save API it should just be an enter-idle
> > > call, and it would expect another call in response to a powersave
> > > wakeup (or it could return in the case of EC=0 type idle).
> > > 
> > > The problem is we may need a new special OPAL call API for
> > > the wakeup case because that would be re-entrant. IMO we also
> > > need something similar for OPAL machine check handling, so we
> > > should think about it and see if something can fit both.
> > > 
> > > I'd like Linux not to have to know about any saving of core
> > > vs thread SPRs or even PSSCR or STOP meanings. Just use an
> > > idle state number it got from dt.  
> > 
> > We don't want OPAL to be the normal path. Only the "oops, we don't know
> > about that processor/idle_state combination/version, use OPAL as a
> > fallback". The cost of an OPAL call is too high otherwise.
> 
> Right, so we should make OPAL do the whole thing (except catch the
> SRESET wakeup which Linux has to do and has well architected SRR1
> bits).
> 
> > 
> > We could have a separate OPAL entry point for the wakeup case but
> > putting the entirety of the enter/exit into OPAL is complicated.
> > 
> > We have to arbitrate between multiple threads entering different
> > states. We don't know until we exit how deep the core actually went and
> > what actually needs to be restored. It's a function of the SRR1 bits on
> > return *and* the state that was requested.
> > 
> > There's also the need to synchronize/rendez-vous threads on wakeup in
> > some cases such as TB resync, and dealing with big vs. small core.
> > 
> > Doing it all in OPAL would require *all* stop states to go to OPAL, I
> > don't think that's a great idea for performance.
> 
> Oh you want Linux native and OPAL drivers to be used simultaneously?
> Is that the right thing to optimise for?

Yes, ideally Linux should handle all stop states and related
save/restore.  We want to fallback to OPAL as a option to use the
deeper stop states even if it has some overheads.  This is a fallback
option to provide kernel level compatibility on different platforms.

Ideally we would expect newer kernels to handle all stop states
optimally without calling OPAL, but if we still miss something, then
atleast through device-tree we can tell kernel to call OPAL for this
stop state rather than just disabling the state completely.

We would expect shallow and fast stop states to be handled by kernel
and fallback to OPAL only for deeper states.

--Vaidy