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

[Gautham R Shenoy]

Hello Ben, Nicholas,

On Mon, Jul 23, 2018 at 05:14:07PM +1000, Benjamin Herrenschmidt 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.

Yes. This is the intended usecase so that the stop state is not
dropped by the kernel, and can be used if the support for save/restore
exists in OPAL. In order to support this, an additional change that is
required in the newly proposed device-tree is a different latency_ns
and residency_ns values should the OPAL based save/restore be used, so
that the cpuidle driver in the kernel will pick it less often than if
the support for the stop state was available in the Kernel.

> 
> 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.

And the PLS value in PSSCR which tells us precisely how deep a state
did the CPU/Core transition to. 

> 
> 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.

This was one of the reasons why the current implementation offloads
only the save/restore task to OPAL and retains the rest of the things
(handling the synchronization, determining the first thread in the
core) in the kernel, since there can be stop states which the Kernel
is capable of handling.


> 
> Cheers
> Ben.

--
Thanks and Regards
gautham.

> 
>