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

[Sean Christopherson <seanjc@google.com>]

On Sat, Aug 08, 2026, David Woodhouse wrote:
> On Thu, 2026-08-06 at 16:35 -0700, Sean Christopherson wrote:
> > 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.