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

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

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@xxxxxxxxxx>
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>

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 <dwmw@xxxxxxxxxxxx>

Attachment: smime.p7s
Description: S/MIME cryptographic signature