Re: [PATCH kvm-unit-tests] KVM: x86: add hyperv clock test case

[Paolo Bonzini <pbonzini@redhat.com>]

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.  If the scale remains the same and the jump is forwards,
we write a new offset in the Hyper-V TSC reference page.

If you want to prepare a patch to do this, that would be great.  (Hint
for debugging: you can define a random MSR that does the offset update,
and call it from the testcase).

Still, the drift that I get on my machine is really excessive, and I
should look into it more.  Marcelo, does it ring a bell?  Any reason why
get_kernel_ns() would be more precise than kvmclock?  The computer has
been up only for about 25 hours.

Paolo