[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