lkml.org 
[lkml]   [2023]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH RFC] x86/tsc: Make recalibration default on for TSC_KNOWN_FREQ cases
Date
On Mon, May 22 2023 at 16:47, Feng Tang wrote:
> On Mon, May 22, 2023 at 10:14:08AM +0200, Thomas Gleixner wrote:
>> On Mon, May 22 2023 at 11:30, Feng Tang wrote:
>> Are any of these affected platforms shipping already or is this just
>> Intel internal muck?
>
> Paul and Rui can provide more info. AFAIK, those problems were raised
> by external customers, so the platform were already shipped from
> Intel. But I'm not sure they are commercial versions or early
> engineering drops.

So its at a company which knows how to update firmware, right?

>> So why do you force this on everyone?
>
> How about we keep the optional parameter, and enforce the check for
> bare metal platforms which got TSC frequency info from CPUID(0x15),
> like:

What prevents a hypervisor from providing this info in CPUID(0x15)?

> @@ -670,8 +670,10 @@ unsigned long native_calibrate_tsc(void)
> * frequency and is the most accurate one so far we have. This
> * is considered a known frequency.
> */
> - if (crystal_khz != 0)
> + if (crystal_khz != 0) {
> setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
> + tsc_force_recalibrate = 1;
> + }
>
> /*
> * Some Intel SoCs like Skylake and Kabylake don't report the crystal

and five lines further down:

/*
* For Atom SoCs TSC is the only reliable clocksource.
* Mark TSC reliable so no watchdog on it.
*/
if (boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT)
setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);

So its reliable and needs recalibration against hardware which does not
exist.

Thanks,

tglx

\
 
 \ /
  Last update: 2023-05-22 13:51    [W:0.797 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site