From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBPkw-0005tl-8R for qemu-devel@nongnu.org; Mon, 28 Nov 2016 12:30:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBPkr-0000gF-CV for qemu-devel@nongnu.org; Mon, 28 Nov 2016 12:30:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44622) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBPkr-0000fp-7t for qemu-devel@nongnu.org; Mon, 28 Nov 2016 12:30:13 -0500 References: <62d634ab-70ad-4be7-1622-f2e3a9d865fe@redhat.com> <20161114145054.GA28663@amt.cnet> <67bffd95-2e4e-7273-c154-a3fdfe622387@redhat.com> <20161114154015.GA30048@amt.cnet> <20161114171318.GA6336@amt.cnet> <14044cda-054d-94eb-8d91-7ad3a1e0869e@redhat.com> <20161114181518.GA14076@amt.cnet> <20161117121637.GA13404@amt.cnet> <1023a283-77a7-45e5-8877-6264e08d0658@redhat.com> <20161128163648.GA4028@amt.cnet> From: Paolo Bonzini Message-ID: Date: Mon, 28 Nov 2016 18:30:06 +0100 MIME-Version: 1.0 In-Reply-To: <20161128163648.GA4028@amt.cnet> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Juan Quintela , Radim Krcmar , Eduardo Habkost On 28/11/2016 17:36, Marcelo Tosatti wrote: > If the source masterclock is disabled, then the guest does > not enable the optimization to not use a global variable=20 > to guarantee monotonicity. Therefore there will be no=20 > time backwards events (the timer backwards events crashed=20 > guests, and are the reason for reading from guest memory). >=20 > So if there are no flaws in the reasoning above,=20 > no, there is no need to read from memory if=20 > masterclock is disabled. Yeah, the reasoning is sound. So you go from what Eduardo and I were thinking: if last KVM_GET_CLOCK was not reliable then read from memory to this: if last KVM_GET_CLOCK was not reliable && masterclock is enabled read from memory but: - on an old kernel, the left side is always true and the right side is unknown (so we must assume it's true and read from memory) - on a new kernel, the two sides of the "&&" are exactly the opposite, so the result is always false and then it becomes if old kernel then read from memory Got it finally. :) Paolo > Can you state the reasons why you think it should be enabled? >=20