[Skiboot] [PATCH v3 4/7] SLW: Add opal_slw_set_reg support for power9

[Vaidyanathan Srinivasan]

* Stewart Smith <stewart at linux.vnet.ibm.com> [2017-09-04 17:34:29]:

> Akshay Adiga <akshay.adiga at linux.vnet.ibm.com> writes:
> > This OPAL call is made from Linux to OPAL to configure values in
> > various SPRs after wakeup from a deep idle state.
> >
> > Signed-off-by: Akshay Adiga <akshay.adiga at linux.vnet.ibm.com>
> > ---
> >  hw/slw.c | 52 ++++++++++++++++++++++++++++++++++------------------
> >  1 file changed, 34 insertions(+), 18 deletions(-)
> 
> I know you're not the one who introduced the OPAL call, but it'd be
> great if you could add in some documentation in doc/opal-api/ to cover
> exactly what the behaviour/use of OPAL_SLW_SET_REG is.

OPAL_SLW_SET_REG is used to inform low-level firmware to restore
a given value of SPR when there is a state loss.  The actual set of
SPR that is supported is platform dependent.  We should document the
details.
 
> A bit strange is how firmware is the only thing that's allowed to touch
> HID0 (as all the bits move around and we need special incantations to
> change the register), but we expect an OS to know that it needs to
> explicitly set HID0 (and on some processors more) to be restored.

That is the idea, but the notion of firmware included hypervisor
software ;) !  On POWER8 we have a need for kernel to change
hypervisor behaviour by setting HID registers.  We have improved in
POWER9 and ISAv3.0 where we don't make hypervisor or host kernel touch
more of the HIDs.  We expect these corner cases with respect to ISA to
get resolved over time.
 
> I gather we don't have any real written down rules about what registers
> may/may not need restoring on future processors/stop states?

Thats right, from POWER8 to POWER9 we had lots of implementation
dependent logic to restore SPRs.  The new STOP framework in POWER9
will smoothen out these corner cases.  It will be easy for us to
document from OPAL to kernel what exactly is lost and how to
restore them.

> Maybe Vaidy knows the future direction here? Would be be making a safe
> bet if we introduced some DT properties of exactly what registers should
> be set to be restored from a firmware perspective?

Yes, using device tree to describe what is lost in each STOP state is
the idea going forward.  Further the low level registers like HIDs and
HRMOR should be managed by OPAL as far as possible and not even have
a need for the kernel to make explicit calls to OPAL_SLW_SET_REG for
implementation dependent registers.

We will always have a bunch of SPRs known to kernel like HSPRG0 and we
would like the state to be restores by low-level hardware and firmware
so that we save cycle and reduce wakeup latency.

This OPAL_SLW_SET_REG call is the API to leverage the low level state
management hardware and microcode to restore specific SPR for kernel
on wakeup from deep idle state.  In future we will have device tree
describing what SPRs the kernel should provide to this API and what
other SPR should be managed purely in software.

--Vaidy