From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZe9-0004Ox-1f for qemu-devel@nongnu.org; Tue, 06 May 2014 03:18:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WhZe1-00027C-HV for qemu-devel@nongnu.org; Tue, 06 May 2014 03:18:36 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53642 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WhZe1-00026z-Am for qemu-devel@nongnu.org; Tue, 06 May 2014 03:18:29 -0400 Message-ID: <53688CC3.7040001@suse.de> Date: Tue, 06 May 2014 09:18:27 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1399297882-3444-1-git-send-email-agraf@suse.de> <20140505232343.GA20638@amt.cnet> <20140505233120.GA23113@amt.cnet> In-Reply-To: <20140505233120.GA23113@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 On 06.05.14 01:31, Marcelo Tosatti wrote: > On Mon, May 05, 2014 at 08:23:43PM -0300, 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". >> >>> However, I've seen cases where the kvmclock guest structure >>> indicates a time more recent than the kvm returned time. > This should not happen because the value returned by KVM_GET_CLOCK > (get_kernel_ns() + kvmclock_offset) should be relatively in sync > with what is seen in the guest via kvmclock read. > Yes, and it isn't. Any ideas why it's not? This patch really just uses the guest visible kvmclock time rather than the host view of it on migration. There is definitely something very broken on the host's side since it does return a smaller time than the guest exposed interface indicates. Alex