From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751391AbdAPTtn (ORCPT ); Mon, 16 Jan 2017 14:49:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37938 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750834AbdAPTtk (ORCPT ); Mon, 16 Jan 2017 14:49:40 -0500 Date: Mon, 16 Jan 2017 17:47:18 -0200 From: Marcelo Tosatti To: Radim Krcmar , Miroslav Lichvar Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Richard Cochran Subject: Re: [patch 3/3] PTP: add kvm PTP driver Message-ID: <20170116194715.GA8017@amt.cnet> References: <20170113120319.777765254@redhat.com> <20170113155657.GD22440@potion> <20170113174014.GA9310@amt.cnet> <20170116162653.GA32097@potion> <20170116165411.GA2386@potion> <20170116170827.GB2501@amt.cnet> <20170116172758.GB31452@potion> <20170116173909.GA4639@amt.cnet> <20170116180147.GD31452@potion> <20170116193655.GA7649@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170116193655.GA7649@amt.cnet> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 16 Jan 2017 19:49:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote: > On Mon, Jan 16, 2017 at 07:01:48PM +0100, Radim Krcmar wrote: > > > Sorry the clock difference is 10ns now. So the guest clock is off by _10 ns_ > > > of the host clock. > > > > That is pretty good. > > Yes. > > > > You are suggesting to use getcrosststamp instead, to drop the (rdtsc() - > > > guest_tsc) part ? > > > > Yes, it results in simpler code, doesn't create dependency on the > > dreaded kvmclock, and is the best we can currently do wrt. precision. Even if the PHC sync algorithm manages to detect that the clock read is incorrect, consider the following: Variability in the VM-entry code path, such as cache effects and interrupts would cause certain readings to be longer then the average (assuming an average where cache is hot). Using the TSC removes this variability, which can be large in case of non realtime guests, where you do: 1. kvm_hypercall. 2. read host realtime clock. 3. schedule out qemu-kvm vcpu. 4. schedule in qemu-kvm vcpu. So using the delta between read host realtime and ->gettime64 increases precision and decreases variability. > Sorry, unless i am misunderstanding how this works, it'll get the guest clock > 2us behind, which is something not wanted. > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past, > this means Chrony will sync the guest clock to > > host realtime - 2us > > Is that correct? >