linux-kernel - Re: [PATCH RFC] x86/tsc: Make recalibration default on for TSC_KNOWN

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: <ZGzOK9xkeQTnleWB@feng-clx>
Date:   Tue, 23 May 2023 22:31:07 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...el.com>,
        "H . Peter Anvin" <hpa@...or.com>, <paulmck@...nel.org>,
        <rui.zhang@...el.com>, <x86@...nel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] x86/tsc: Make recalibration default on for
 TSC_KNOWN_FREQ cases

On Tue, May 23, 2023 at 10:11:15AM +0200, Peter Zijlstra wrote:
> On Tue, May 23, 2023 at 09:18:23AM +0800, Feng Tang wrote:
> > On Mon, May 22, 2023 at 06:11:58PM +0200, Peter Zijlstra wrote:
> > > On Mon, May 22, 2023 at 11:20:15PM +0800, Feng Tang wrote:
> > > 
> > > > And I don't understand the commit log: "On Intel GOLDMONT Atom SoC
> > > > TSC is the only reliable clocksource. We mark TSC reliable to avoid
> > > > watchdog on it."
> > > > 
> > > > Clearly the Denventon I found today has both HPET and ACPI_PM timer:
> > > > 
> > > >   [root@...0 ~]# grep .  /sys/devices/system/clocksource/clocksource0/*
> > > >   /sys/devices/system/clocksource/clocksource0/available_clocksource:tsc hpet acpi_pm
> > > >   /sys/devices/system/clocksource/clocksource0/current_clocksource:tsc
> > > >   
> > > > The lscpu info is:
> > > >   
> > > >   Architecture:                    x86_64
> > > >   CPU op-mode(s):                  32-bit, 64-bit
> > > >   Address sizes:                   39 bits physical, 48 bits virtual
> > > >   Byte Order:                      Little Endian
> > > >   CPU(s):                          12
> > > >   On-line CPU(s) list:             0-11
> > > >   Vendor ID:                       GenuineIntel
> > > >   BIOS Vendor ID:                  Intel(R) Corporation
> > > >   Model name:                      Intel(R) Atom(TM) CPU C3850 @ 2.10GHz
> > > >   BIOS Model name:                 Intel(R) Atom(TM) CPU C3850 @ 2.10GHz  CPU @ 2.1GHz
> > > >   BIOS CPU family:                 43
> > > >   CPU family:                      6
> > > >   Model:                           95
> > > >   Thread(s) per core:              1
> > > >   Core(s) per socket:              12
> > > >   Socket(s):                       1
> > > >   Stepping:                        1
> > > > 
> > > > Maybe this cpu model (0x5F) has been used by some type of platforms
> > > > which has met the false alarm watchdog issue.
> > > 
> > > It has them; but they are not *reliable*.
> >  
> > Yes, that's possible. I tried to CC the author Bin in case he can
> > provide more background or information for his statement, but his
> > email address is unreachable now.
> 
> IIRC HPET stops in C10 or something stupid like that, I forgot what the
> problem with ACPI_PM is.

Yes, that HPET issue is a common one for several generations of
client platforms like Baytrail, Coffee Lake etc.