[RFC/DISCUSSION] x86/tsc: Handling legacy PIT fallback calibration on modern platforms

[RFC/DISCUSSION] x86/tsc: Handling legacy PIT fallback calibration on modern platforms

[Hahn, Matthias]

(sorry, resending as plain text)

Hi everyone,

We have recently observed an issue regarding TSC calibration fallback on
modern client/server platforms (specifically Raptor Lake and newer) when
running inside restricted virtualized environments.

Problem Background:
-------------------
In arch/x86/kernel/tsc.c, quick_pit_calibrate() assumes that legacy port
I/O accesses (ports 0x61, 0x43, 0x42) take roughly ~1 us per read.

On modern platforms, however, legacy port I/O cycle latency has increased
substantially. In benchmark comparisons between older platforms (e.g.
Broadwell-DE) and modern silicon (Raptor Lake), 1024 PIT reads took ~2.7M
cycles on BDX compared to ~21.3M cycles on RPL (~8x-10x slower, yielding
~10-20 us per read).

As a consequence:
1. When running as a guest under hypervisors that restrict or mask modern
   enumeration methods (CPUID 0x15H / 0x16H, MSR_PLATFORM_INFO, paravirt
   clocks, or HPET), the guest falls back to quick_pit_calibrate().
2. The inflated I/O latency breaks the internal loop budget:
   `d1 + d2 >= (delta * MAX_QUICK_PIT_ITERATIONS) >> 11`
   triggers prematurely, causing quick calibration to fail fast ("Fast TSC
   calibration failed") and leading either to refined calibration timeouts
   or inaccurate tsc_khz determination.

Questions / Points for Discussion:
----------------------------------
While hypervisors clearly *should* expose reliable timing interfaces
(CPUID 0x15H, pvclock, etc.), fallback robustness in the kernel remains
desirable.

1. Deprecation / Removal:
   Is there an appetite to deprecate or completely drop legacy 8254 PIT
   calibration from modern x86 kernels, or is strict backward compatibility
   for legacy systems still requiring it?

2. Guarding by Processor Generation:
   Should PIT calibration be automatically bypassed / refused on modern
   CPU families (e.g. based on family/model or modern feature presence)
   where 8254 hardware timing assumptions are no longer valid?

3. Heuristic Adjustments:
   Alternatively, should the loop timing heuristics in quick_pit_calibrate()
   be adapted to account for multi-microsecond port I/O latencies on modern
   chipsets?

I would appreciate thoughts and guidance from the x86 and timer maintainers
on how the community prefers to handle this architectural gap.

Thanks,
Matthias Hahn

--
Dr. Matthias Hahn
CCG ECG ECE CSEE EMEA
SW Application Engineer
Phone:  +49 (0)89 9914-3865
Mobile: +49 (0)173 6514 578
matthias.hahn@intel.com
 
VISIT US AT: http://www.intel.com
 
Address:
Intel Deutschland GmbH
Dornacher Str. 1
85622 Feldkirchen / Munich
Germany

________________________________________
Intel Deutschland GmbH 

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany 

Tel: +49 (89) 99143-0 

www.intel.de 

Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Board: Sonja Pierer

Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC/DISCUSSION] x86/tsc: Handling legacy PIT fallback calibration on modern platforms

[Sean Christopherson]

On Tue, Oct 06, 2026, Matthias Hahn wrote:
> (sorry, resending as plain text)
> 
> Hi everyone,
> 
> We have recently observed an issue regarding TSC calibration fallback on
> modern client/server platforms (specifically Raptor Lake and newer) when
> running inside restricted virtualized environments.

Can you give this Linux-as-a-guest TSC cleanup series a spin?  Among other things,
it addresses the problem of a constant, stable TSC being marked unstable because
the thing being used to calibrate the TSC is itself unstable.

https://lore.kernel.org/all/20260806233609.212337-1-seanjc@google.com

Re: [RFC/DISCUSSION] x86/tsc: Handling legacy PIT fallback calibration on modern platforms

[Ping K. Jiang]

 > We have recently observed an issue regarding TSC calibration fallback on
 > modern client/server platforms (Specifically Raptor Lake and newer) when
 > running inside restricted virtualized environments.
 >
 > On modern platforms, however, legacy port I/O cycle latency has increased
 > substantially. In benchmark comparisons between older platforms (e.g.
 > Broadwell-DE) and modern silicon (Raptor Lake), 1024 PIT reads took ~2.7M
 > cycles on BDX compared to ~21.3M cycles on RPL (~8x-10x slower, yielding
 > ~10-20 us per read).
 >

Dear Dr. Hahn,

I was reproducing this on i5-14600KF. My PIT delay wass ~13000 cycles,
resulting in TSC calibration with 30 ppm error, tested by running
`sudo dmesg | grep TSC` on host and VM.

I wonder why I can't reproduce it.
My motherboard is 'B760M-PLUS WIFI II'.

Thanks!
Ping Jiang

RE: [RFC/DISCUSSION] x86/tsc: Handling legacy PIT fallback calibration on modern platforms

[Hahn, Matthias]

Dear Ping Jiang

Thx for following up. 

> I was reproducing this on i5-14600KF. My PIT delay wass ~13000 cycles, resulting in TSC calibration with 30 ppm error, tested by running `sudo dmesg | grep TSC` on host and VM.
>
> I wonder why I can't reproduce it.
> My motherboard is 'B760M-PLUS WIFI II'.

Did you by chance select "IO fabric low latency" in FW (BIOS) config or TCC mode which would include that knob? Then it's expected that you see lower latencies for PIT and you might not be able to reproduce (sorry I didn't mention). 

Regards,
Matthias

--
Dr. Matthias Hahn
Intel Deutschland GmbH
Phone: +49 (0)89 9914-3865
Mobile: +49 (0)173 6514578

-----Original Message-----
From: Ping K. Jiang <jiang_kangping@outlook.com> 
Sent: Wednesday, October 7, 2026 5:51 PM
To: Hahn, Matthias <matthias.hahn@intel.com>; linux-kernel@vger.kernel.org; x86@kernel.org
Cc: tglx@linutronix.de; mingo@redhat.com; bp@alien8.de; dave.hansen@linux.intel.com; peterz@infradead.org
Subject: Re: [RFC/DISCUSSION] x86/tsc: Handling legacy PIT fallback calibration on modern platforms

 > We have recently observed an issue regarding TSC calibration fallback on  > modern client/server platforms (Specifically Raptor Lake and newer) when  > running inside restricted virtualized environments.
 >
 > On modern platforms, however, legacy port I/O cycle latency has increased  > substantially. In benchmark comparisons between older platforms (e.g.
 > Broadwell-DE) and modern silicon (Raptor Lake), 1024 PIT reads took ~2.7M  > cycles on BDX compared to ~21.3M cycles on RPL (~8x-10x slower, yielding  > ~10-20 us per read).
 >

Dear Dr. Hahn,

I was reproducing this on i5-14600KF. My PIT delay wass ~13000 cycles, resulting in TSC calibration with 30 ppm error, tested by running `sudo dmesg | grep TSC` on host and VM.

I wonder why I can't reproduce it.
My motherboard is 'B760M-PLUS WIFI II'.

Thanks!
Ping Jiang
________________________________________
Intel Deutschland GmbH 

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany 

Tel: +49 (89) 99143-0 

www.intel.de 

Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Board: Sonja Pierer

Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC/DISCUSSION] x86/tsc: Handling legacy PIT fallback calibration on modern platforms

[Thomas Gleixner]

Matthias!

On Tue, Oct 06 2026 at 12:53, Hahn, Matthias wrote:
> We have recently observed an issue regarding TSC calibration fallback on
> modern client/server platforms (specifically Raptor Lake and newer) when
> running inside restricted virtualized environments.
>
> Problem Background:
> -------------------
> In arch/x86/kernel/tsc.c, quick_pit_calibrate() assumes that legacy port
> I/O accesses (ports 0x61, 0x43, 0x42) take roughly ~1 us per read.
>
> On modern platforms, however, legacy port I/O cycle latency has increased
> substantially. In benchmark comparisons between older platforms (e.g.
> Broadwell-DE) and modern silicon (Raptor Lake), 1024 PIT reads took ~2.7M
> cycles on BDX compared to ~21.3M cycles on RPL (~8x-10x slower, yielding
> ~10-20 us per read).

That's a known problem and the proper solution is that the firmware
provides the TSC frequency in CPUID. Those CPUID fields have been there
for over a decade (starting with Skylake IIRC), but are still not
populated consistently.

> As a consequence:
> 1. When running as a guest under hypervisors that restrict or mask modern
>    enumeration methods (CPUID 0x15H / 0x16H, MSR_PLATFORM_INFO, paravirt
>    clocks, or HPET), the guest falls back to quick_pit_calibrate().

Trivial solution: Fix the hypervisor.

> 2. The inflated I/O latency breaks the internal loop budget:
>    `d1 + d2 >= (delta * MAX_QUICK_PIT_ITERATIONS) >> 11`
>    triggers prematurely, causing quick calibration to fail fast ("Fast TSC
>    calibration failed") and leading either to refined calibration timeouts
>    or inaccurate tsc_khz determination.

Nothing the kernel can do about.

> Questions / Points for Discussion:
> ----------------------------------
> While hypervisors clearly *should* expose reliable timing interfaces
> (CPUID 0x15H, pvclock, etc.), fallback robustness in the kernel remains
> desirable.
>
> 1. Deprecation / Removal:
>    Is there an appetite to deprecate or completely drop legacy 8254 PIT
>    calibration from modern x86 kernels, or is strict backward compatibility
>    for legacy systems still requiring it?

Disable it and half of the machines out there will fail to initialize
the TSC early. That's not about legacy systems. AMD does not provide
CPUID0x15/16 at all and I just logged into two recent Intel machines
which _have_ them, but the content is all zeros.

> 2. Guarding by Processor Generation:
>    Should PIT calibration be automatically bypassed / refused on modern
>    CPU families (e.g. based on family/model or modern feature presence)
>    where 8254 hardware timing assumptions are no longer valid?

And if CPUID 0x15/0x16 is not populated then the kernel uses a crystal
ball to determine the TSC frequency, right?

> 3. Heuristic Adjustments:
>    Alternatively, should the loop timing heuristics in quick_pit_calibrate()
>    be adapted to account for multi-microsecond port I/O latencies on modern
>    chipsets?

Good luck with that.

> I would appreciate thoughts and guidance from the x86 and timer maintainers
> on how the community prefers to handle this architectural gap.

We prefer that the hardware/hypervisor people finally understand that
not providing the nominal frequency in CPUID or some other
architecturally defined way is a patently bad idea and subsequently get
their act together and fix the underlying problem instead of expecting
magical software workarounds in the kernel to paper over them.

One potential workaround would be to utilize the _CPC ACPI tables, which
contain the nominal P0 frequency on both Intel and AMD, but those are
not accessible during early boot and in restricted guest environments
probably not available at all.

The kernel community has told both vendors for way more than a decade
that a architecturally guaranteed way to determine the TSC frequency is
required to solve all the underlying problems. The virtualization folks
worked around that by implementing their own paravirt clocks as a
wrapper around TSC, but that's a horrible and fragile hack as well.

Looking at the TSC evolution: It only took two decades of complaining to
get a frequency invariant TSC, so maybe in ten years from now we have a
architecturally guaranteed way to determine the frequency.

Thanks,

        tglx