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) <[email protected]> > Signed-off-by: Sean Christopherson <[email protected]>
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... Reviewed-by: David Woodhouse <[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
