From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roman Kagan <rkagan@virtuozzo.com>
Subject: Re: [PATCH kvm-unit-tests v2] KVM: x86: add hyperv clock test case
Date: Mon, 30 May 2016 21:09:58 +0300
Message-ID: <20160530180957.GA4993@rkaganb.sw.ru>
References: <1461259285-28472-1-git-send-email-rkagan@virtuozzo.com>
 <20160523215506.GA23886@amt.cnet>
 <20160523234402.GB23886@amt.cnet>
 <20160525183002.GA18943@rkaganb.sw.ru>
 <20160529222924.GB6738@amt.cnet>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
	"Denis V. Lunev" <den@openvz.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-am1on0114.outbound.protection.outlook.com ([157.56.112.114]:56480
	"EHLO emea01-am1-obe.outbound.protection.outlook.com"
	rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
	id S1161330AbcE3SKK (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 30 May 2016 14:10:10 -0400
Content-Disposition: inline
In-Reply-To: <20160529222924.GB6738@amt.cnet>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Sun, May 29, 2016 at 07:29:27PM -0300, Marcelo Tosatti wrote:
> On Wed, May 25, 2016 at 09:30:02PM +0300, Roman Kagan wrote:
> > On Mon, May 23, 2016 at 08:44:03PM -0300, Marcelo Tosatti wrote:
> > > On Mon, May 23, 2016 at 06:55:06PM -0300, Marcelo Tosatti wrote:
> > > which fails once you run 
> > > 
> > > void main(void)
> > > {
> > >         int ret;
> > >         struct timex tx;
> > >         char *ptr;
> > > 
> > >         memset((void*)&tx, 0, sizeof(tx));
> > > 
> > >         tx.freq = -6553600;
> > >         //tx.freq = -237507;
> > >         tx.modes = ADJ_FREQUENCY;
> > >         ret = adjtimex(&tx);
> > 
> > Right, which is a problem with kvm-clock too (as I wrote in another
> > thread, pvclock_gtod_data updates don't currently trigger per-VM
> > masterclock updates).  I'm still struggling through the multiple lengthy
> > discussions trying to figure out if it's a bug or a feature...
> 
> Its a bug, i am writing an improvement based on Paolo's change to
> update the multiplier. 
> 
> But the hyperv tsc reference page patches should not depend on it.

Unfortunately it does: since hyperv tsc reference page doesn't have
seqlock semantics, it's emulated (per Paolo's suggestion) by marking the
contents invalid with seqcount == 0, which makes Windows use MSR-based
clock.  And the two clocks are not expected to diverge.

Roman.