From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct Date: Tue, 16 Feb 2016 14:48:17 +0100 Message-ID: <20160216134816.GA21944@amt.cnet> References: <1454944711-33022-1-git-send-email-pbonzini@redhat.com> <1454944711-33022-5-git-send-email-pbonzini@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org To: Paolo Bonzini Return-path: Content-Disposition: inline In-Reply-To: <1454944711-33022-5-git-send-email-pbonzini@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Mon, Feb 08, 2016 at 04:18:31PM +0100, Paolo Bonzini wrote: > When an NTP server is running, it may adjust the time substantially > compared to the "official" frequency of the TSC. A 12 ppm change > sums up to one second per day. > > This already shows up if the guest compares kvmclock with e.g. the > PM timer. It shows up even more once we add support for the Hyper-V > TSC page, because the guest expects it to be in sync with the time > reference counter; effectively the time reference counter is just a > slow path to access the same clock that is in the TSC page. > > Therefore, we want kvmclock to provide the host kernel's > ktime_get_boot_ns() value, at least if the master clock is active. > To do so, reverse-compute the host's "actual" TSC frequency from > pvclock_gtod_data and return it from kvm_get_time_and_clockread. Paolo, You'd have to generate an update to the guest structures as well, to reflect the new {mult,shift} values calculated by the host. Here: /* disable master clock if host does not trust, or does not * use, TSC clocksource */ if (gtod->clock.vclock_mode != VCLOCK_TSC && atomic_read(&kvm_guest_has_master_clock) != 0) queue_work(system_long_wq, &pvclock_gtod_work); No? At first, i'm afraid this might be heavy, so it might be interesting to rate limit the update operation.