On 28/01/2016 15:50, Paolo Bonzini wrote: > > > On 28/01/2016 15:25, Andrey Smetanin wrote: >>> >>> Andrey, the test has a relative error of approximately 3 parts >>> per million on my machine. In other words it drifts by 3 >>> microseconds every second, which I don't think is acceptable. >>> The problem is that virtual_tsc_khz is 2593993 while the actual >>> frequency is more like 2594001 kHz. >>> >>> But I have a problem in general with using tsc_khz to compute >>> the hyperv reference clock scale. The maximum possible accuracy >>> on a 2.5 GHz machine is around 200 ppb, corresponding to a drift >>> of about 16 milliseconds per day. Perhaps we could use Linux >>> (and kvmclock's) timekeeping parameters to derive the tsc_scale >>> and tsc_offset? >> >> Probably need to check the code. But can we just workaround it >> by host periodic timer with period ~10ms which will issue(by scheduling >> vcpu KVM_REQ_*) refresh of guest tsc page to prevent drifting? > > That would kill performance. > > However, after a bit more testing, kvmclock seems to have the same > issue. The formula to convert the kvmclock scale to the hyper-v one is > > tsc_to_nsec_system_mul * 2^(32 + tsc_shift)/100 > > which on my system gives 0xFCA52ED99999999; that's within 0.1 ppb of > what the Hyper-V code computes from a 2593993 kHz TSC. > > So the patch seems okay, but we need to adjust kvm_guest_time_update to > support the Hyper-V clock. In kvm_guest_time_update we can compute a > new scale and offset; if the scale changes, we set sequence to 0. If > the new offset is such that the clock would go backwards, we set > sequence to 0. ... No, that doesn't work. The clock would go backwards because the TIME_REF_COUNT MSR is counting more slowly than the TSC-based clock. I guess what we can do is to compute the TSC reference page parameters as soon as the master clock is activated, and use them instead of get_kernel_ns() to compute the reference count MSR (again if the master clock is activated). But I'm now a bit wary to enable the hyper-v TSC reference page without knowing the effects of a divergence between the two mechanisms. Especially if a migration could lead to a switch from one to the other and thus to the time going backwards. Paolo -- 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
