Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 19 Apr 2024 16:53:32 -0700 | Subject | Re: [PATCH 2/2] KVM: selftests: Add KVM/PV clock selftest to prove timer drift correction | From | "Chen, Zide" <> |
| |
On 4/19/2024 12:34 PM, David Woodhouse wrote: > On 19 April 2024 18:13:16 BST, "Chen, Zide" <zide.chen@intel.com> wrote: >> I'm wondering what's the underling theory that we definitely can achieve >> ±1ns accuracy? I tested it on a Sapphire Rapids @2100MHz TSC frequency, >> and I can see delta_corrected=2 in ~2% cases. > > Hm. Thanks for testing! > > So the KVM clock is based on the guest TSC. Given a delta between the guest TSC T and some reference point in time R, the KVM clock is expressed as a(T-R)+r, where little r is the value of the KVM clock when the guest TSC was R, and (a) is the rate of the guest TSC. > > When set the clock with KVM_SET_CLOCK_GUEST, we are changing the values of R and r to a new point in time. Call the new ones Q and q respectively. > > But we calculate precisely (within 1ns at least) what the KVM clock would have been with the *old* formula, and adjust our new offset (q) so that at our new reference TSC value Q, the formulae give exactly the same result. > > And because the *rates* are the same, they should continue to give the same results, ±1ns. > > Or such *was* my theory, at least.
Thanks for the explanation.
> > Would be interesting to see it disproven with actual numbers for the old+new pvclock structs, so I can understand where the logic goes wrong. > > Were you using frequency scaling?
I can see similar ~2% failure ratio w/ or w/o commenting out configure_scaled_tsc().
| ![\](/images/icornerr.gif) |