linux-kernel - Re: [RFC PATCH 05/10] alpha: Primitive support for CPU power down.

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]

Message-ID: <51E69911.3000804@twiddle.net>
Date:	Wed, 17 Jul 2013 06:16:01 -0700
From:	Richard Henderson <rth@...ddle.net>
To:	Matt Turner <mattst88@...il.com>
CC:	linux-kernel@...r.kernel.org, ink@...assic.park.msu.ru,
	linux-alpha@...r.kernel.org
Subject: Re: [RFC PATCH 05/10] alpha: Primitive support for CPU power down.

On 07/16/2013 10:17 PM, Matt Turner wrote:
> On Tue, Jul 16, 2013 at 10:34 AM, Richard Henderson <rth@...ddle.net> wrote:
>> Use WTINT to wait for the next interrupt.  Squash the WTINT call
>> if the PALcode doesn't support it (e.g. MILO).  No attempt is yet
>> made to skip clock ticks during normal scheduling in order to stay
>> in power down mode longer.
> 
> The architecture reference manual says
> 
>> The counter, PCC, may increment at a lower rate or may stop entirely
>> during wtint execution. This side effect is implementation dependent.
> 
> Is that anything to worry about?

Hmm, yes.  It means that we can't use both this and rpcc as a clocksource.
Which we can't do while SMP either, so perhaps that's not so bad.  So, right
now, with an SMP EV6 system we ought not worry.  Care to report whether that
hypothesis is true?

It may well be a tradeoff we want to CONFIG though, since nothing in the EV5
thru PCA56 can make use of the power down state, and were often uniprocessor
systems...

>> @@ -243,6 +243,18 @@ do_entIF(unsigned long type, struct pt_regs *regs)
>>                                (const char *)(data[1] | (long)data[2] << 32),
>>                                data[0]);
>>                 }
>> +               if (type == 4) {
>> +                       /* If CALL_PAL WTINT is not supported by the PALcode,
>> +                          "emulate" it by overwriting the insn.  */
> 
> The pseudo-code for WTINT contains an IF(implemented) check, where the
> ELSE case just does v0 <- 0. So is overwriting with nop just an
> optimization to avoid the (expensive) PAL call? If it is, could we
> clarify the comment?

No, notice where this code is: entIF, aka SIGILL.  Looking at MILO sources
I can tell you that WTINT isn't implemented at all.  Overwriting with the
mov insn is what I call "emulating" the unimplemented PALcall.


r~
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/