From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZcN-0002TO-K0 for qemu-devel@nongnu.org; Tue, 06 May 2014 03:16:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhZcG-0001J0-5j for qemu-devel@nongnu.org; Tue, 06 May 2014 03:16:47 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53613 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZcF-0001It-Uy for qemu-devel@nongnu.org; Tue, 06 May 2014 03:16:40 -0400 Message-ID: <53688C56.6020109@suse.de> Date: Tue, 06 May 2014 09:16:38 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1399297882-3444-1-git-send-email-agraf@suse.de> <20140505232343.GA20638@amt.cnet> In-Reply-To: <20140505232343.GA20638@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvmclock: Ensure time in migration never goes backward List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Nick Thomas On 06.05.14 01:23, Marcelo Tosatti wrote: > Hi Alexander, > > On Mon, May 05, 2014 at 03:51:22PM +0200, Alexander Graf wrote: >> When we migrate we ask the kernel about its current belief on what the guest >> time would be. > KVM_GET_CLOCK which returns the time in "struct kvm_clock_data". Yes :) > >> However, I've seen cases where the kvmclock guest structure >> indicates a time more recent than the kvm returned time. > More details please: > > 1) By what algorithm you retrieve > and compare time in kvmclock guest structure and KVM_GET_CLOCK. > What are the results of the comparison. > And whether and backwards time was visible in the guest. I've managed to get my hands on a broken migration stream from Nick. There I looked at the curr_clocksource structure and saw that the last seen time on the kvmclock clock source was greater than the value that the kvmclock device migrated. > 2) What is the host clocksource. > > The test below is not a good one because: > > T1) KVM_GET_CLOCK (save s->clock). > T2) save env->tsc. > > The difference in scaled time between T1 and T2 is larger than 1 > nanosecond, so the > > (time_at_migration > s->clock) > > check is almost always positive (what matters though is whether > time backwards event can be seen reading kvmclock in the guest). Yeah, at first I was thinking it makes sense to just not use the KVM_GET_CLOCK value at all because it's redundant to the in-memory values. Maybe that is the better alternative after all. Alex