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 18:02:05 +0100 Message-ID: <20150122170201.GA1485@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> <54C0B065.8070801@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marcelo Tosatti , kvm-devel To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46616 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752707AbbAVRCK (ORCPT ); Thu, 22 Jan 2015 12:02:10 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0MH29PY008010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 22 Jan 2015 12:02:09 -0500 Content-Disposition: inline In-Reply-To: <54C0B065.8070801@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2015-01-22 09:10+0100, Paolo Bonzini: > On 21/01/2015 18:00, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > 2015-01-21 12:16-0200, Marcelo Tosatti: > >> On Wed, Jan 21, 2015 at 03:09:27PM +0100, Radim Kr=C4=8Dm=C3=A1=C5= =99 wrote: > >>> 2015-01-20 15:54-0200, Marcelo Tosatti: > >>>> SuSE's 2.6.16 kernel fails to boot if the delta between tsc_time= stamp > >>>> and rdtsc is larger than a given threshold: > >>> [...] > >>>> Disable masterclock support (which increases said delta) in case= the > >>>> boot vcpu does not use MSR_KVM_SYSTEM_TIME_NEW. > >>> > >>> Why do we care about 2.6.16 bugs in upstream KVM? > >> > >> Because people do use 2.6.16 guests. > >=20 > > (Those people probably won't use 3.19+ host ... >=20 > Why not? If you are a cloud provider, you cannot really know what gue= sts > your customer run. People running decade old kernels are likely conservative and changing the host is unsafe too. (This bug was introduced later.) I doubt they would risk VMs on a cloud that doesn't ensure stability. (It's a weak reason, I should have argued that the buggy guest code wasn't in Linux 2.6.16 and probably only dwells in a distribution whos= e general support ended on 2013-07-31.) > >> What is the benefit of removing support for MSR_KVM_SYSTEM_TIME ? > >=20 > > The maintainability of the code increases. It would look as if we = never > > made the mistake with MSR_KVM_SYSTEM_TIME & MSR_KVM_WALL_CLOCK. > > (I like when old code looks as if we wrote it from scratch.) >=20 > Everybody does, and everybody obsesses over splitting patches so that > they look as if the code had been split that way from scratch. Heck,= I > probably spend over half of my development time inside "git rebase -i= ". (+ most of the rest is verification and testing :) > But it's just not how reality works, and it must show sooner or later= =2E (Yeah, I am keenly observing and trying the predict the outcome.) > >> Supporting old guests is important. > >=20 > > It comes at a price. > > (Mutually exclusive goals are important as well.) >=20 > Marcelo's patch is not too high a price. Is it ugly? Yes. Could it= be > any better? No, because the ugliness is not his fault, it's intrinsi= c > in the problem it solves. Agreed, I've learned the circumstances that make it the best solution. (I didn't acknowledge it as a problem and documentation states that KVM_FEATURE_CLOCKSOURCE "may be removed in the future". The the-future in the future.) Thanks to you and Marcelo.