From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932486AbcBPOAr (ORCPT ); Tue, 16 Feb 2016 09:00:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41228 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932561AbcBPOAn (ORCPT ); Tue, 16 Feb 2016 09:00:43 -0500 Date: Tue, 16 Feb 2016 14:48:17 +0100 From: Marcelo Tosatti To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct 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 Content-Disposition: inline In-Reply-To: <1454944711-33022-5-git-send-email-pbonzini@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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.