On Thu, 2026-05-21 at 14:17 -0700, Sean Christopherson wrote: > > > That seems reasonable. Where does the call to > > native_calibrate_tsc() > > happen; is that from determine_cpu_tsc_frequencies()? > > Yep.
Great, thanks.
> static bool __init determine_cpu_tsc_frequencies(bool early,
> unsigned int
> known_cpu_khz,
> unsigned int
> known_tsc_khz)
> {
> /* Make sure that cpu and tsc are not already calibrated */
> WARN_ON(cpu_khz || tsc_khz);
>
> if (early) {
> /*
> * Early CPU calibration can only use methods that
> are available
> * early in boot (obviously).
> */
> if (known_cpu_khz)
> cpu_khz = known_cpu_khz;
> else
> cpu_khz = native_calibrate_cpu_early();
> if (known_tsc_khz)
> tsc_khz = known_tsc_khz;
> else
> tsc_khz = native_calibrate_tsc();
> } else {
> cpu_khz = pit_hpet_ptimer_calibrate_cpu();
> }
If, after all that, we still end up in the case where we *do* have to
calibrate it against a legacy timer (which sadly IIRC is the case even
on some fairly modern AMD generations), could we round the answer?
We currently have *far* more precision than accuracy, leading to values
like 2399997kHz which change every boot (and end up being what gets
*advertised* to guests on such a host... and then unless we're careful
to avoid it, we end up trying to *scale* a different host's TSC down
from 2399998 to 2399997 for a guest which is migrated from the first
host...)
We should just fix them (e.g. to 2400000kHz) and let NTP sort them out.
Something like "round to the nearest MHz if that's within ±10PPM"?
smime.p7s
Description: S/MIME cryptographic signature
