On Fri, Apr 22, 2016 at 08:08:47PM +0200, Paolo Bonzini wrote: > On 22/04/2016 15:32, Roman Kagan wrote: > > The first value is derived from the kvm_clock's tsc_to_system_mul and > > tsc_shift, and matches hosts's vcpu->hw_tsc_khz. The second is > > calibrated using emulated HPET. The difference is those +14 ppm. > > > > This is on i7-2600, invariant TSC present, TSC scaling not present. > > > > I'll dig further but I'd appreciate any comment on whether it was within > > tolerance or not. > > The solution to the bug is to change the Hyper-V reference time MSR to > use the same formula as the Hyper-V TSC-based clock. Likewise, > KVM_GET_CLOCK and KVM_SET_CLOCK should not use ktime_get_ns(). Umm, I'm not sure it's a good idea... E.g. virtualized HPET sits in userspace and thus uses clock_gettime(CLOCK_MONOTONIC), so the drift will remain. AFAICT the root cause is the following: KVM master clock uses the same multiplier/shift as the vsyscall time in host userspace. However, the offsets in vsyscall_gtod_data get updated all the time with corrections from NTP and so on. Therefore even if the TSC rate is somewhat miscalibrated, the error is kept small in vsyscall time functions. OTOH the offsets in KVM clock are basically never updated, so the error keeps linearly growing over time. Roman. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
