On Fri, 2026-05-15 at 12:19 -0700, Sean Christopherson wrote: > When running as a TDX guest, explicitly override the TSC frequency > calibration routine with CPUID-based calibration 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 the CPU frequency calibration routine as is, since the > TDX-Module doesn't provide any guarantees with respect to CPUID.0x16. > > Opportunistically add a comment explaining that CoCo TSC initialization > needs to come after hypervisor specific initialization. > > Cc: Kirill A. Shutemov <[email protected]> > Signed-off-by: Sean Christopherson <[email protected]>
I don't much like stuffing the lapic_timer_period... but I'll give you 'least awful option'. For now. Reviewed-by: David Woodhouse <[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
