From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: What time is it kvm-clock? Date: Wed, 24 Feb 2016 15:14:09 +0100 Message-ID: <56CDBAB1.6090405@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Marcelo Tosatti , Andy Lutomirski , Peter Hornyack To: Owen Hofmann , KVM General Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55642 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753882AbcBXOON (ORCPT ); Wed, 24 Feb 2016 09:14:13 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 24/02/2016 03:31, Owen Hofmann wrote: > Specifically, what underlying source of time should be exposed through > kvm-clock and other paravirtual ABIs like the HyperV reference tsc > page? Recently a couple of threads on kvm-list, along with attempts > to produce reliable behavior from kvm-clock on our systems have > highlighted a tension between the current implementation of kvm-clock > and potentially diverging goals for paravirt time. Here are a few: > > 1) kvmclock doesn't work, help?: http://www.spinics.net/lists/kvm/msg125039.html > 2) kvmclock: improve accuracy: http://www.spinics.net/lists/kvm/msg127215.html > 3) KVM-clock: http://www.spinics.net/lists/kvm/msg127774.html > > This question is mostly in regards to kvm-clock in masterclock mode > (with PVCLOCK_TSC_STABLE set). In this mode, is kvm-clock intended to > expose a source of time that is more 'true' than the underlying TSC? > For example, by passing through NTP correction from the host. For the > current implementation, the answer seems to be... why not both? Once > programmed, kvm-clock or the HyperV TSC page will advance with the TSC > multiplied by the frequency specified by kvm. On the other hand, > KVM_GET_CLOCK, KVM_SET_CLOCK, and the Windows reference counter MSR > are measured against corrected time from the host. A guest reading its > pvclock gets a very different result from a host KVM_GET_CLOCK if the > guest has run long enough to for TSC to diverge from NTP time. Right, in fact that's why QEMU is not really using KVM_GET_CLOCK anymore. In retrospect, the "fix" in QEMU was probably a bad idea. It would have been better to fix KVM_GET_CLOCK. > To me, kvm-clock and the HyperV TSC page are extremely effective as > simply a more enlightened path to the host TSC. Maintaining a > high-performance path to the TSC in the face of updates is tricky - > see the extended comment in pvclock_update_vm_gtod_copy, or the > discussion on the patchset in (2). Is the cost of auditing that the > path from host gettimeofday update -> kvm -> guest pvclock -> guest > gettimeofday both tracks host time correctly and does not produce any > backwards warps worth the added value, if it exists? As an > alternative, implementing KVM_GET_CLOCK or the reference time MSR as a > function of the last update to kvm-clock or the reference TSC page, > respectively, sounds very straightforward. Yes, we could do that too. I think that vgettsc and do_monotonic_boot also would have to use the TSC frequency instead the NTP-adjusted host clock. > (Outside of masterclock mode, the requirement that the client > synchronizes across cpus for montonicity smoothes over a lot of > complexity - periodically updating kvm-clock to the current time is > simple and works.) > > Regardless of my opinion, I think that a clear statement of the design > goals for kvm-clock (and kvm's implementation of the reference TSC > page) would be valuable. Since we cannot change the past, having kvmclock synchronize with the host TSC frequency is the only choice we can make. Paolo