linux-kernel - Re: [RFC 0/3] Integrate Support for self-save and determine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 3 Jan 2020 15:05:51 -0800
From:   Ram Pai <linuxram@...ibm.com>
To:     Pratik Rajesh Sampat <psampat@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
        mpe@...erman.id.au, svaidy@...ux.ibm.com, ego@...ux.vnet.ibm.com,
        pratik.sampat@...ibm.com
Subject: Re: [RFC 0/3] Integrate Support for self-save and determine

On Wed, Dec 04, 2019 at 03:02:52PM +0530, Pratik Rajesh Sampat wrote:
> Currently the stop-api supports a mechanism called as self-restore
> which allows us to restore the values of certain SPRs on wakeup from a
> deep-stop state to a desired value. To use this, the Kernel makes an
> OPAL call passing the PIR of the CPU, the SPR number and the value to
> which the SPR should be restored when that CPU wakes up from a deep
> stop state.
> 
> Recently, a new feature, named self-save has been enabled in the
> stop-api, which is an alternative mechanism to do the same, except
> that self-save will save the current content of the SPR before
> entering a deep stop state and also restore the content back on
> waking up from a deep stop state.
> 
> This patch series aims at introducing and leveraging the self-save feature in
> the kernel.
> 
> Now, as the kernel has a choice to prefer one mode over the other and
> there can be registers in both the save/restore SPR list which are sent
> from the device tree, a new interface has been defined for the seamless
> handing of the modes for each SPR.
> 
> A list of preferred SPRs are maintained in the kernel which contains two
> properties:
> 1. supported_mode: Helps in identifying if it strictly supports self
>                    save or restore or both.

Will be good to capture the information that, 'supported_mode' gets 
initialized using the information from the device tree.

> 2. preferred_mode: Calls out what mode is preferred for each SPR. It
>                    could be strictly self save or restore, or it can also
>                    determine the preference of  mode over the other if both
>                    are present by encapsulating the other in bitmask from
>                    LSB to MSB.

and 'preferred_mode'  is statically initialized.

> Below is a table to show the Scenario::Consequence when the self save and
> self restore modes are available or disabled in different combinations as
> perceived from the device tree thus giving complete backwards compatibly
> regardless of an older firmware running a newer kernel or vise-versa.
> 
> SR = Self restore; SS = Self save
> 
> .-----------------------------------.----------------------------------------.
> |             Scenario              |                Consequence             |
> :-----------------------------------+----------------------------------------:
> | Legacy Firmware. No SS or SR node | Self restore is called for all         |
> |                                   | supported SPRs                         |
> :-----------------------------------+----------------------------------------:
> | SR: !active SS: !active           | Deep stop states disabled              |
> :-----------------------------------+----------------------------------------:
> | SR: active SS: !active            | Self restore is called for all         |
> |                                   | supported SPRs                         |
> :-----------------------------------+----------------------------------------:
> | SR: active SS: active             | Goes through the preferences for each  |
> |                                   | SPR and executes of the modes          |
> |                                   | accordingly. Currently, Self restore is|
> |                                   | called for all the SPRs except PSSCR   |
> |                                   | which is self saved                    |
> :-----------------------------------+----------------------------------------:
> | SR: active(only HID0) SS: active  | Self save called for all supported     |
> |                                   | registers expect HID0 (as HID0 cannot  |
> |                                   | be self saved currently)               |

Not clear, how this will be conveyed to the hypervisor? Through the
device tree or through some other means?


> :-----------------------------------+----------------------------------------:
> | SR: !active SS: active            | currently will disable deep states as  |
> |                                   | HID0 is needed to be self restored and |
> |                                   | cannot be self saved                   |
> '-----------------------------------'----------------------------------------'
> 
> Pratik Rajesh Sampat (3):
>   powerpc/powernv: Interface to define support and preference for a SPR
>   powerpc/powernv: Introduce Self save support
>   powerpc/powernv: Parse device tree, population of SPR support
> 
>  arch/powerpc/include/asm/opal-api.h        |   3 +-
>  arch/powerpc/include/asm/opal.h            |   1 +
>  arch/powerpc/platforms/powernv/idle.c      | 431 ++++++++++++++++++---
>  arch/powerpc/platforms/powernv/opal-call.c |   1 +
>  4 files changed, 379 insertions(+), 57 deletions(-)
> 
> -- 
> 2.21.0

-- 
Ram Pai