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

[Thomas Gleixner <tglx@linutronix.de>]

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