[Skiboot] [PATCH v6 0/3] powerpc/powernv: Introduce interface for self-restore support
Gautham R Shenoy
ego at linux.vnet.ibm.com
Tue Apr 14 17:11:49 AEST 2020
Hello Pratik,
On Thu, Mar 26, 2020 at 12:40:31PM +0530, Pratik Rajesh Sampat wrote:
> v5: https://lkml.org/lkml/2020/3/17/944
> Changelog
> v5-->v6
> 1. Updated background, motivation and illuminated potential design
> choices
> 2. Re-organization of patch-set
> a. Split introducing preference for optimization from 1/1 to patch 3/3
> b. Merge introducing self-save API and parsing the device-tree
> c. Introduce a supported mode called KERNEL_SAVE_RESTORE which
> outlines and makes kernel supported SPRs for save-restore more
> explicit
>
[..snip..]
> Presenting the design choices in front of us:
>
> Design-Choice 1:
> ----------------
> A simple implementation is to just replace self-restore calls with
> self-save as it is direct super-set.
>
> Pros:
> A simple design, quick to implement
>
>
> Cons:
> * Breaks backward compatibility. Self-restore has historically been
> supported in the firmware and an old firmware running on an new
> kernel will be incompatible and deep stop states will be cut.
> * Furthermore, critical SPRs which need to be restored
> before 0x100 vector like HID0 are not supported by self-save.
>
> Design-Choice 2:
> ----------------
> Advertise both self-restore and self-save from OPAL including the set
> of registers that each support. The kernel can then choose which API
> to go with.
> For the sake of simplicity, in case both modes are supported for an
> SPR by default self-save would be called for it.
>
> Pros:
> * Backwards compatible
>
> Cons:
> Overhead in parsing device tree with the SPR list
>
> Possible optimization with Approach2:
> -------------------------------------
> There are SPRs whose values don't tend to change over time and invoking
> self-save on them, where the values are gotten each time may turn out to
> be inefficient. In that case calling a self-restore where passing the
> value makes more sense as, if the value is same, the memory location
> is not updated.
> SPRs that dont change are as follows:
> SPRN_HSPRG0,
> SPRN_LPCR,
> SPRN_PTCR,
> SPRN_HMEER,
> SPRN_HID0,
We can just pick self-save wherever available and fallback to
self-restore when self-save support is not avaiable for any SPR.
The optimization that you mention here can be revisited if the
additional latency due to self-save becomes observable (Note that both
stop4 and stop5 have wakeup latency between 200-500us).
>
> The values of PSSCR and MSR change at runtime and hence, the kernel
> cannot determine during boot time what their values will be before
> entering a particular deep-stop state.
>
> Therefore, a preference based interface is introduced for choosing
> between self-save or self-restore between for each SPR.
> The per-SPR preference is only a refinement of
> approach 2 purely for performance reasons. It can be dropped if the
> complexity is not deemed worth the returns.
>
> Patches Organization
> ====================
> Design Choice 2 has been chosen as an implementation to demonstrate in
> the patch series.
>
> Patch1:
> Devises an interface which lists all the interested SPRs, along with
> highlighting the support of mode.
> It is an isomorphic patch to replicate the functionality of the older
> self-restore firmware for the new interface
>
> Patch2:
> Introduces the self-save API and leverages upon the struct interface to
> add another supported mode in the mix of saving and restoring. It also
> enforces that in case both modes are supported self-save is chosen over
> self-restore
>
> The commit also parses the device-tree and populate support for
> self-save and self-restore in the supported mask
>
> Patch3:
> Introduce an optimization to allow preference to choose between one more
> over the one when both both modes are supported. This optimization can
> allow for better performance for the SPRs that don't change in value and
> hence self-restore is a better alternative, and in cases when it is
> known for values to change self-save is more convenient.
>
> Pratik Rajesh Sampat (3):
> powerpc/powernv: Introduce interface for self-restore support
> powerpc/powernv: Introduce support and parsing for self-save API
> powerpc/powernv: Preference optimization for SPRs with constant values
>
> .../bindings/powerpc/opal/power-mgt.txt | 18 +
> arch/powerpc/include/asm/opal-api.h | 3 +-
> arch/powerpc/include/asm/opal.h | 1 +
> arch/powerpc/platforms/powernv/idle.c | 385 +++++++++++++++---
> arch/powerpc/platforms/powernv/opal-call.c | 1 +
> 5 files changed, 351 insertions(+), 57 deletions(-)
>
> --
> 2.17.1
>
More information about the Skiboot
mailing list