From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwUlC-0005Hp-1N for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:48:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwUl9-0003MO-10 for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:48:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45152) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwUl8-0003MC-RP for qemu-devel@nongnu.org; Tue, 18 Oct 2016 09:48:50 -0400 Date: Tue, 18 Oct 2016 15:48:46 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20161018134846.GB3492@potion> References: <20161014212031.GQ3275@thinpad.lan.raisama.net> <20161017094708.GB31691@amt.cnet> <20161017145008.GA2307@potion> <72b8c6b3-f08a-735a-e283-99d0195dcf7d@redhat.com> <20161017211101.GD3275@thinpad.lan.raisama.net> <20161017235846.GA22657@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161017235846.GA22657@amt.cnet> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] invtsc + migration + TSC scaling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Eduardo Habkost , Paolo Bonzini , qemu-devel@nongnu.org, kvm@vger.kernel.org 2016-10-17 21:58-0200, Marcelo Tosatti: > On Mon, Oct 17, 2016 at 07:11:01PM -0200, Eduardo Habkost wrote: >> On Mon, Oct 17, 2016 at 06:24:38PM +0200, Paolo Bonzini wrote: >> > On 17/10/2016 16:50, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> > > 2016-10-17 07:47-0200, Marcelo Tosatti: >> [...] >> > >> since Linux guests use kvmclock and Windows guests use Hyper-V >> > >> enlightenment, it should be fine to disable 2). >> >=20 >> > ... and 1 too. >> >=20 >> > We should also blacklist the TSC deadline timer when invtsc is not >> > available. >=20 > Actually, a nicer fix would be to check the different=20 > frequencies and scale the deadline relative to the difference.=20 I think that KVM can already be configured to do that. Paolo, we hit that TSC deadline bug bacause QEMU doesn't set the TSC frequency if it would result in software scaling (which needs to update guest TSC and kvmclock on every entry)? Thanks. (I just noticed a minor bug: KVM doesn't use hardware scaling when the TSC frequency delta is small.) > This would take care of both patched and non-patched guests. >=20 > On a related note, what was the goal of Radim's paravirtual deadline > TSC timer? It's be paravirtual kvmclock timer -- just giving the deadline in other another time frame. It won't confuse OS that expect the deadline timer to behave like it should. :)