linux-kernel - Re: [PATCH 0/4] x86/platform/UV: Update TSC support

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: <df8cabdd-a5f9-9e2d-b089-cf0f3dbe16eb@hpe.com>
Date:   Fri, 29 Sep 2017 08:19:22 -0700
From:   Mike Travis <mike.travis@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Bin Gao <bin.gao@...ux.intel.com>,
        Prarit Bhargava <prarit@...hat.com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Andrew Banman <andrew.banman@....com>,
        Russ Anderson <russ.anderson@....com>,
        linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 0/4] x86/platform/UV: Update TSC support



On 9/29/2017 1:46 AM, Peter Zijlstra wrote:
> On Thu, Sep 28, 2017 at 01:03:39PM -0500, mike.travis@....com wrote:
>>
>> The UV BIOS goes to considerable effort to get the TSC synchronization
>> accurate across the entire system.  Included in that are multiple chassis
>> that can have 32+ sockets.  The architecture does support an external
>> high resolution clock to aid in maintaining this synchronization.
>>
>> The resulting TSC accuracy set by the UV system BIOS is much better
>> than the generic kernel TSC ADJUST functions.  This is important for
>> applications that read the TSC values directly for accessing data bases.
>>
>> *   These patches disable an assumption made by the kernel tsc sync
>>      functions that Socket 0 in the system should have a TSC ADJUST
>>      value of zero.  This is not correct when the chassis are reset
>>      asynchronously to each other so which TSC's should be zero is
>>      not predictable.
>>
>> *   When the system BIOS determines that the TSC is not stable, it then
>>      sets a flag so the UV kernel setup can set the "tsc is unstable"
>>      flag.  A patch now prevents the kernel from attempting to fix the
>>      TSC causing a slew of warning messages.
>>
>> *   It also eliminates another avalanche of warning messages from older
>>      BIOS that did not have the TSC ADJUST MSR (ex. >3000 msgs in a 32
>>      socket Skylake system).  It now notes this with a single warning
>>      message and then moves on with fixing them.
> 
> So I would still like to get clarification on how ART works (or likely
> doesn't) on your systems. I think for now its fairly prudent to kill
> detect_art() on UV.

I tested with both detect_art enabled and disabled and didn't notice a 
difference though I wasn't sure what test to run to verify whether it 
was being used or not.  (I'd be glad to run some specific test if one 
can be suggested?)  The num/denom setting for a 2100Mhz CPU was 168/2 if 
that information helps?

> Also, while indeed not strictly required, that TSC_ADJUST==0 test on
> bootcpu is nice for consumer systems, BIOS did something 'weird' if that
> is not true. Is something like is_uv_system() available early enough?

My previous version of the patches had me setting a flag that could be 
checked by the tsc_sanitize_first_cpu() function and disable the 
requirement of "TSC == 0 on socket 0" for any arch that specified it.
(And UV did set that flag.)

But Thomas said it was "hackery" and that TSC being 0 on socket 0 was no 
longer a requirement.  So I took it out for this version and made the 
"TSC == 0 on socket 0" no longer the default for any arch.
> 
> Other than that, the patches look good to me.
>