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 14:59:28 +0100 Message-ID: <20150122135928.GA20498@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> 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]:54229 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751969AbbAVN7c (ORCPT ); Thu, 22 Jan 2015 08:59:32 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0MDxVen030974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 22 Jan 2015 08:59:31 -0500 Content-Disposition: inline In-Reply-To: <20150122014038.GA5307@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 2015-01-21 23:40-0200, Marcelo Tosatti: > On Wed, Jan 21, 2015 at 06:00:37PM +0100, Radim Kr=C4=8Dm=C3=A1=C5=99= wrote: > > 1) The bug happens because a guest expects greater precision. > > I consider that as a guest problem. kvmclock never guaranteed > > anything, so unmet expectations should be a recoverable error. >=20 > delta =3D pvclock_data.tsc_timestamp - RDTSC >=20 > Guest expects delta to be smaller than a given threshold. It does > not expect greater precision. >=20 > Size of delta does not affect precision. I don't understand what the guest wants to achieve with the delta. I thought that checking this only made sense if the guest didn't believ= e that PV clock works with large delta. And they only want precision. (What else is there on a clock?) Disclaimer: I haven't read the code. (It wasn't in vanilla 2.6.16.) > > 2) With time, the probability that 2.6.16 is used is getting lower, > > while people looking at KVM's code appear. > > - At what point are we going to drop 2.6.16 support? > > (We shouldn't let mistakes drag us down forever ... > > Or are we dooming KVM on purpose?) >=20 > One of the features of virtualization is to be able to run old=20 > operating systems? True, I'll assign higher priority to it. > > 3) The patch made me ask more silly questions than it answered :) > > (Why can't other software depend on previous behavior? >=20 > Documentation/virtual/kvm/msr.txt: >=20 > whose data will be filled in by the hypervisor periodically. > Only one write, or registration, is needed for each VCPU. The= interval > between updates of this structure is arbitrary and implementa= tion-dependent. > The hypervisor may update this structure at any time it sees = fit until > anything with bit0 =3D=3D 0 is written to it. Exactly, this made me think it is not a KVM problem. (And I wondered why wouldn't we yield to other misuses of it.) > > > Supporting old guests is important. > >=20 > > It comes at a price. > > (Mutually exclusive goals are important as well.) >=20 > This phrase is awkward. Overlapping goals are negative, > then? (think of a large number of totally overlapping goals). Even if both mutually exclusive goals are positive, we can only choose one. (Sorry, I don't see the neccessity between overlapping goals and negativity.)