From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH kvm-unit-tests] KVM: x86: add hyperv clock test case Date: Thu, 28 Jan 2016 15:50:30 +0100 Message-ID: <56AA2AB6.3000802@redhat.com> References: <1453989899-30351-1-git-send-email-pbonzini@redhat.com> <56AA24EB.6000504@virtuozzo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Roman Kagan , "Denis V. Lunev" , Marcelo Tosatti To: asmetanin@virtuozzo.com, kvm@vger.kernel.org Return-path: Received: from mail-wm0-f67.google.com ([74.125.82.67]:32890 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932685AbcA1Oue (ORCPT ); Thu, 28 Jan 2016 09:50:34 -0500 Received: by mail-wm0-f67.google.com with SMTP id r129so4221966wmr.0 for ; Thu, 28 Jan 2016 06:50:34 -0800 (PST) In-Reply-To: <56AA24EB.6000504@virtuozzo.com> Sender: kvm-owner@vger.kernel.org List-ID: 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