linux-kernel - Re: [PATCH] Allow Intel platforms to declare unsynchronized TSC to kernel

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: <4BB07636.7010708@jp.fujitsu.com>
Date:	Mon, 29 Mar 2010 18:43:18 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	tglx@...utronix.de, linux-kernel@...r.kernel.org, torvalds@...l.org
Subject: Re: [PATCH] Allow Intel platforms to declare unsynchronized TSC to
 kernel

(2010/03/29 16:46), Andi Kleen wrote:
> Andi Kleen <andi@...stfloor.org> writes:
> 
>> Allow Intel platforms to declare unsynchronized TSC to kernel
>>
>> [This came out of a private discussion with Linus last week]
> 
> Ping?  Please review this patch.
> 
> -Andi

Does "constant" implicitly means "synchronized"?
IMHO the answer is no.

Following commit tells us that there could be
"constant-but-unsynchronized TSC":
 6c56ccecf05fafe100ab4ea94f6fccbf5ff00db7
> So, reenable TSC sync test even on constant and non-stop TSC systems.

Quote from the patch description of commit:
 40fb17152c50a69dc304dd632131c2f41281ce44
> Add support for CPUID_0x80000007_Bit8 on Intel CPUs as well. This bit means
> that the TSC is invariant with C/P/T states and always runs at constant
> frequency.
>
> With Intel CPUs, we have 3 classes
> * CPUs where TSC runs at constant rate and does not stop n C-states
> * CPUs where TSC runs at constant rate, but will stop in deep C-states
> * CPUs where TSC rate will vary based on P/T-states and TSC will stop in
>   deep C-states.

It looks like that "invariant" also means "constant."

I suppose your change is intended to allow newer platform to declare
"not invariant", instead of "not invariant but constant."
Humm, but how things change...?  Still newer platform cannot declare
one of 3 classes.  Which class is "never on newer platform"?
Or we need to have 4th new class? 

At least I think your patch description needs some update,
to get more comments without confusing reviewers.


Thanks,
H.Seto

--
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/