linux-kernel - Re: [PATCH] use 64bit timer for hpet

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:   Thu, 08 Jul 2021 13:17:14 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linux <zhaoyan.liao@...ux.alibaba.com>
Cc:     mingo@...hat.com, hpa@...or.com, dwmw@...zon.co.uk,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
        songmuchun@...edance.com, likunkun@...edance.com,
        guancheng.rjk@...baba-inc.com, duanxiongchun@...edance.com,
        wenan.mao@...ux.alibaba.com
Subject: Re: [PATCH] use 64bit timer for hpet

Liao!

On Thu, Jul 08 2021 at 11:11, Linux wrote:
>> 2021年7月7日 下午6:04，Thomas Gleixner <tglx@...utronix.de> 写道：
>> Seriously? The wrap-around time for 32bit HPET @24MHz is ~3 minutes.
>
> In some cases, our system will be very busy, and the timeout of 3 minutes 
> is not an exaggeration. Then, the system considers that the tsc clock is 
> inaccurate and switches the tsc clock to the hpet clock, which brings 
> greater performance overhead.

Sorry, keeping the softirq from running for 3 minutes is simply out of
spec. If the sysadmin decides to do so, then he can keep the pieces.

>> Aside of that the reason why the kernel does not support 64bit HPET is
>> that there are HPETs which advertise 64bit support, but the
>> implementation is buggy.
>
> Can you tell me what is the buggy with the 64-bit hpet clock?

I forgot the details, but when I tried moving HPET to 64bit it did not
work on one of my machines due to an erratum and other people reported
similar issues on different CPUs/chipsets.

TBH, I'm not interested at all to chase down these buggy implementations
and have yet another pile of quirks.

> In my opinion, it is unreasonable to use a lower-bit width clock to
> calibrate a higher-bit width clock, and the hardware already supports
> the higher-bit width.

There is nothing unreasonable with that, really:

   1) This is not about calibration. It's a sanity check to catch
      broken TSC implementations.

      Aside of that it _IS_ very reasonable for calibration. We even
      calibrate TSC via the PIT if we can't get the frequency from
      the firmware.

   2) Expecting that the softirq runs within 3 minutes is very
      reasonable.

   3) On modern machines this is usually not longer necessary. If you
      are confident that the TSC on your system is stable then you
      can disable the watchdog via the kernel command line.

      There is also effort underway to come up with reasonable
      conditions to avoid the watchdog on those CPUs in the first place.

   4) For any system which actually has to use HPET the 64bit HPET is
      overhead. HPET access is slow enough already.

   5) 32bit HPET has to be supported as well and just claiming that a
      64bit access on 32bit HPET does not matter is just wishful
      thinking. Aside of breaking 32bit kernels along the way which
      is just a NONO.
      
#4 and #5 were the main reason why I gave up on it - aside of the
discovery that there are broken implementations out there.

So no, there is really no compelling reason to support 64bit HPETs.

Thanks,

        tglx
---
P.S: Please trim your replies.