From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBPlq-0006NN-Jl for qemu-devel@nongnu.org; Mon, 28 Nov 2016 12:31:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBPlm-0000x2-Ci for qemu-devel@nongnu.org; Mon, 28 Nov 2016 12:31:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33786) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBPlm-0000ws-6h for qemu-devel@nongnu.org; Mon, 28 Nov 2016 12:31:10 -0500 References: <20161121105002.291554230@redhat.com> <20161121105052.598267440@redhat.com> <20161128141322.GB14328@thinpad.lan.raisama.net> <20161128164522.GB4028@amt.cnet> <20161128171201.GD14328@thinpad.lan.raisama.net> From: Paolo Bonzini Message-ID: <3dba7b62-bfd2-6551-d983-89541afbcee4@redhat.com> Date: Mon, 28 Nov 2016 18:31:04 +0100 MIME-Version: 1.0 In-Reply-To: <20161128171201.GD14328@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qemu patch V3 2/2] kvmclock: reduce kvmclock difference on migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Marcelo Tosatti Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, Dr David Alan Gilbert , Juan Quintela , Radim Krcmar On 28/11/2016 18:12, Eduardo Habkost wrote: >>> > >=20 >>> > > Why not use src_use_reliable_get_clock here, too? (Maybe rename >>> > > it to simply clock_is_reliable?) >> >=20 >> > Because you end up mixing two mental ideas (one: whether the source >> > has KVM_GET_CLOCK, second: whether the destination has KVM_GET_CLOCK= =20 >> > into one variable). I find it more confusing than not. >> > Maybe its just my limited brain but i find it >> > confusing. > I find it simpler and easier to reason about. Me too---note that it's not "whether X had reliable KVM_GET_CLOCK" but rather "whether the last read came from a reliable KVM_GET_CLOCK". However... >>> > > You can change kvm_get_clock() to kvm_get_clock(KVMClockState*), >>> > > and make it update both s->clock and s->clock_is_reliable. With >>> > > this, s->clock and s->clock_is_reliable will be always in sync, >>> > > and have a single code path for both local restore and migration: >> >=20 >> > There should not be a single path for migration/runtime cases:=20 >> > on migration, we care whether the source used reliable KVM_GET_CLOCK= . >> >=20 >> > On runtime, we care whether the destination uses reliable KVM_GET_CL= OCK. > The conditions may be different, but both can be translated to a > "should we trust the value in s->clock" flag, to simplify the > code (just like Paolo's suggestion on his reply to v1 today). ... I think I understand now: Marcelo is approaching the problem differently. For him it's not an issue of "should we trust the value" but rather it's "is the value going to mess up the guest with backwards time". Which is fine, it just requires some more comments because it's subtle and it looks a lot like the kernel API is being misused (while it's fine). Paolo