Re: [PATCH v6 10/51] x86/tdx: Force TSC frequency with CPUID-based info provided by the TDX-Module

On Sat, Aug 08, 2026, David Woodhouse wrote:

On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:

quoted

When running as a TDX guest, explicitly set the TSC frequency to a known
value, using CPUID-based information, instead of potentially relying on a
hypervisor-controlled PV routine.  For TDX guests, CPUID.0x15 is always
emulated by the TDX-Module, i.e. the information from CPUID is more
trustworthy than the information provided by the hypervisor.

To maintain backwards compatibility with TDX guest kernels that use native
calibration, and because it's the least awful option, retain
native_calibrate_tsc()'s stuffing of the local APIC bus period using the
core crystal frequency.  While it's entirely possible for the hypervisor
to emulate the APIC timer at a different frequency than the core crystal
frequency, the commonly accepted interpretation of Intel's SDM is that APIC
timer runs at the core crystal frequency when that latter is enumerated via
CPUID:

  The APIC timer frequency will be the processor's bus clock or core
  crystal clock frequency (when TSC/core crystal clock ratio is enumerated
  in CPUID leaf 0x15).

If the hypervisor is malicious and deliberately runs the APIC timer at the
wrong frequency, nothing would stop the hypervisor from modifying the
frequency at any time, i.e. attempting to manually calibrate the frequency
out of paranoia would be futile.

Deliberately leave CPU frequency calibration as is, since the TDX-Module
doesn't provide any guarantees with respect to CPUID.0x16.

Expose and use cpuid_get_tsc_info() instead of providing a wrapper to
get the TSC and core crystal frequency, as TDX is the only anticipated
user outside of the TSC code, i.e. adding a helper to dedup the math won't
actually dedup anything.  Having TDX use "struct cpuid_tsc_info" also
avoids the temptation of declaring a local "tsc_khz" variable and thus
unintentionally creating a shadow of the global "tsc_khz".

Cc: Kiryl Shutsemau (Meta) <kas@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>

I don't know if we should set X86_FEATURE_TSC_RELIABLE before bailing
out in the case where cpuid_get_tsc_info() fails, or just not care
about that because it Can Never Happen™? Previously it was set
unconditionally from tdx_early_init().

Whatever...

Heh, yeah, "whatever" is about my thought exactly.  I could go either way.  I
would buy an argument that the TSC itself is still reliable even if the frequency
isn't known.  On the other hand, the frequency could be computed via calibration,
at which point the frequency is no longer reliable and arguably should be sanity
checked.