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] [day] [month] [year] [list]
Date:	Fri, 20 May 2016 11:46:02 +0530
From:	Shreyas B Prabhu <shreyas@...ux.vnet.ibm.com>
To:	Paul Mackerras <paulus@...abs.org>
CC:	mpe@...erman.id.au, linuxppc-dev@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, mikey@...ling.org,
	"ego >> Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>
Subject: Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop
 instruction



On 05/20/2016 10:55 AM, Paul Mackerras wrote:
> 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.

Copying of comment regarding fastsleep workaround was an oversight. It
will not be necessary in POWER9. I'll fix that in the next version.

The need for synchronizing between threads going into and out of
power-saving modes still exists. Resyncing timebase and restoring few
registers still have to be done once per core.
> 
> - 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?
> 

While we could use the same code I felt that handling POWER8 and POWER9
cases in the same file might make the code more complicated.
Gautham suggested we can use the same POWER8 code and use FTR sections
wherever POWER8 and POWER9 deviate. If you feel that is better I can
implement that in the next version.

Thanks,
Shreyas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ