From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roman Kagan <rkagan@virtuozzo.com>
Subject: Re: [PATCH kvm-unit-tests] KVM: x86: add hyperv clock test case
Date: Mon, 25 Apr 2016 11:47:23 +0300
Message-ID: <20160425084722.GA31039@rkaganb.sw.ru>
References: <1453989899-30351-1-git-send-email-pbonzini@redhat.com>
 <20160128162206.GA29344@rkaganb.sw.ru>
 <56B22CB4.9090404@redhat.com>
 <20160421170157.GA16360@rkaganb.sw.ru>
 <20160422133240.GA9108@rkaganb.sw.ru>
 <571A68AF.1030907@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: <kvm@vger.kernel.org>, "Denis V. Lunev" <den@openvz.org>,
	Marcelo Tosatti <mtosatti@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-am1on0102.outbound.protection.outlook.com ([157.56.112.102]:47290
	"EHLO emea01-am1-obe.outbound.protection.outlook.com"
	rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
	id S1753985AbcDYIre (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 25 Apr 2016 04:47:34 -0400
Content-Disposition: inline
In-Reply-To: <571A68AF.1030907@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, Apr 22, 2016 at 08:08:47PM +0200, Paolo Bonzini wrote:
> On 22/04/2016 15:32, Roman Kagan wrote:
> > The first value is derived from the kvm_clock's tsc_to_system_mul and
> > tsc_shift, and matches hosts's vcpu->hw_tsc_khz.  The second is
> > calibrated using emulated HPET.  The difference is those +14 ppm.
> > 
> > This is on i7-2600, invariant TSC present, TSC scaling not present.
> > 
> > I'll dig further but I'd appreciate any comment on whether it was within
> > tolerance or not.
> 
> The solution to the bug is to change the Hyper-V reference time MSR to
> use the same formula as the Hyper-V TSC-based clock.  Likewise,
> KVM_GET_CLOCK and KVM_SET_CLOCK should not use ktime_get_ns().

Umm, I'm not sure it's a good idea...

E.g. virtualized HPET sits in userspace and thus uses
clock_gettime(CLOCK_MONOTONIC), so the drift will remain.

AFAICT the root cause is the following: KVM master clock uses the same
multiplier/shift as the vsyscall time in host userspace.  However, the
offsets in vsyscall_gtod_data get updated all the time with corrections
from NTP and so on.  Therefore even if the TSC rate is somewhat
miscalibrated, the error is kept small in vsyscall time functions.  OTOH
the offsets in KVM clock are basically never updated, so the error keeps
linearly growing over time.

Roman.