Re: [PATCH 1/2] x86/time: use native TSC scaling factors when TSC is not scaled

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Apr 16, 2026 at 01:28:11PM +0200, Jan Beulich wrote:
> On 14.04.2026 12:33, Roger Pau Monne wrote:
> > When running HVM guest in native TSC mode avoid using the recalculated vTSC
> > scaling factors based on the cpu_khz value.  Using the kHz based frequency
> > leads to the TSC scaling values possibly not being the same as the ones
> > used by the per CPU cpu_time->tsc_scale field, which introduces skew
> > between the guest and Xen's calculations of the system time.
> > 
> > On a 2gHz system, where the frequency is possibly detected as 1999999999Hz
> > (note this is a worse-case scenario), the cpu_khz variable will be set to
> > 1999999kHz, and hence 999Hz cycles will be not accounted for per second.
> > Over a second (the time synchronization period), this leads to a skew of:
> > 
> > cycles * 1 / (Hz freq) = 999 / 1999999999 = 499,5ns
> > 
> > So far this has gone unnoticed because the time synchronization rendezvous
> > forces the update of the tsc_timestamp and system_time fields in the vCPU
> > time info area, and hence the skew only accumulates up to the rendezvous
> > period.  Attempting to remove the rendezvous causes the skew to grow
> > unbounded.
> > 
> > Fix by using the native TSC scaling values (as used by Xen) when the guest
> > TSC is not scaled.
> > 
> > Fixes: eab8a90be723 ("x86/time: scale host TSC in pvclock properly")
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > ---
> > I'm worried about the usage of cpu_khz beyond simple printing it for
> > informational purposes.  Overall I think it would be safer to store the
> > frequency in Hz, as to avoid losing the least significant digits.
> > 
> > In any case, that's a different change.
> 
> I'm not quite sure - improving accuracy is of course a good thing, but will
> we ever be able to do any such calculations error free, when already the
> detected frequency isn't exactly precise?

I think getting them fully accurate is not strictly required.  The
specific issue here was that the guest was supposedly running with the
native TSC frequency, but the vCPU time info scaling factors where
(slightly) different from the ones using natively by Xen, hence resulting in a
time skew.

When the guest runs with a different TSC frequency Xen already
accounts for it properly, and hence there's no skew.

However, as noted in the next patch, I don't really see the benefit of
storing the frequency in kHz instead of using plain Hz.

Thanks, Roger.