From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: KVM: x86: workaround SuSE's 2.6.16 pvclock vs masterclock issue Date: Thu, 22 Jan 2015 20:33:31 +0100 Message-ID: <20150122193327.GA6543@potion.brq.redhat.com> References: <20150120175452.GA32680@amt.cnet> <20150121140926.GA9085@potion.brq.redhat.com> <20150121141634.GB718@amt.cnet> <20150121170033.GB9085@potion.brq.redhat.com> <20150122014038.GA5307@amt.cnet> <20150122135928.GA20498@potion.brq.redhat.com> <20150122181253.GA6957@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm-devel , Paolo Bonzini To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49794 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752479AbbAVTdf (ORCPT ); Thu, 22 Jan 2015 14:33:35 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0MJXYgn032703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 22 Jan 2015 14:33:34 -0500 Content-Disposition: inline In-Reply-To: <20150122181253.GA6957@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 2015-01-22 16:12-0200, Marcelo Tosatti: > On Thu, Jan 22, 2015 at 02:59:28PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99= wrote: > > I don't understand what the guest wants to achieve with the delta. >=20 > Neither do I. It seems to assume that TSC delta is unreliable, while=20 > system_timestamp is reliable. >=20 > Therefore if TSC delta is large, request a system_timestamp update, > which keeps TSC delta small. I was wondering how they do that ... kvm clock has like 1 MSR interface= ; multiple registrations are supposed to work? > > I thought that checking this only made sense if the guest didn't be= lieve > > that PV clock works with large delta. And they only want precision= =2E > > (What else is there on a clock?) >=20 > Ok right they assumed TSC was not reliable? Most likely. (And that doing complicated magic is going to help it -- doesn't VMENTRY do pretty much everyting that can be done with unreliable TSC?)