linux-kernel - Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

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, 20 May 2016 15:25:03 +1000
From:	Paul Mackerras <paulus@...abs.org>
To:	"Shreyas B. Prabhu" <shreyas@...ux.vnet.ibm.com>
Cc:	mpe@...erman.id.au, linuxppc-dev@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, mikey@...ling.org
Subject: Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop
 instruction

On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote:
> POWER ISA v3 defines a new idle processor core mechanism. In summary,
>  a) new instruction named stop is added. This instruction replaces
> 	instructions like nap, sleep, rvwinkle.
>  b) new per thread SPR named PSSCR is added which controls the behavior
> 	of stop instruction.
> 
> PSSCR has following key fields
> 	Bits 0:3  - Power-Saving Level Status. This field indicates the lowest
> 	power-saving state the thread entered since stop instruction was last
> 	executed.
> 
> 	Bit 42 - Enable State Loss
> 	0 - No state is lost irrespective of other fields
> 	1 - Allows state loss
> 
> 	Bits 44:47 - Power-Saving Level Limit
> 	This limits the power-saving level that can be entered into.
> 
> 	Bits 60:63 - Requested Level
> 	Used to specify which power-saving level must be entered on executing
> 	stop instruction
> 
> This patch adds support for stop instruction and PSSCR handling.

I notice that you have duplicated a whole lot of assembly code
relating to synchronizing between threads going into and out of
power-saving modes, saving/restoring SPRs, resyncing the timebase, and
so on.

Two questions arise:

- Are we really going to have to do all of that in the same way for
  POWER9 as we did for POWER8?  You even copied over a comment about
  the fastsleep workaround, which I really hope we won't have to do on
  POWER9.  Also, on POWER9, the threads are much more independent, so
  I was not expecting that there would still be shared registers.

- If we do have to do all that, could we use the same code as on
  POWER8 rather than having another copy of all that code?

Paul.