From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH] kvmclock: Ensure time in migration never goes backward Date: Thu, 08 May 2014 09:21:29 +0200 Message-ID: <536B3079.7060109@suse.de> References: <1399297882-3444-1-git-send-email-agraf@suse.de> <20140508013325.GA5474@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from cantor2.suse.de ([195.135.220.15]:48397 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751516AbaEHHVc (ORCPT ); Thu, 8 May 2014 03:21:32 -0400 In-Reply-To: <20140508013325.GA5474@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 08.05.14 03:33, Marcelo Tosatti wrote: > 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. However, I've seen cases where the kvmclock guest structure >> indicates a time more recent than the kvm returned time. >> >> To make sure we never go backwards, calculate what the guest would have seen >> as time at the point of migration and use that value instead of the kernel >> returned one when it's more recent. >> >> While this doesn't fix the underlying issue that the kernel's view of time >> is skewed, it allows us to safely migrate guests even from sources that are >> known broken. >> >> Signed-off-by: Alexander Graf > OK Alexander better move this logic to the kernel, in KVM_GET_CLOCK. > > Otherwise every user of KVM_GET_CLOCK would have to apply the > workaround. Well, the breakage occurs on the *source* of things. So if I have 100 VMs running, I'm pretty sure one of them gets hit by this bug. If I put the workaround in the kernel, I have to take the chance to break some of those 100 VMs to get things rolling. If I put it in QEMU, I can live with a broken migration source. This gets even worse when you want to phase out unfixed host kernels. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiIeB-0006jT-4A for qemu-devel@nongnu.org; Thu, 08 May 2014 03:21:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WiIe3-0000uy-Qs for qemu-devel@nongnu.org; Thu, 08 May 2014 03:21:39 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44668 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiIe3-0000um-K9 for qemu-devel@nongnu.org; Thu, 08 May 2014 03:21:31 -0400 Message-ID: <536B3079.7060109@suse.de> Date: Thu, 08 May 2014 09:21:29 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1399297882-3444-1-git-send-email-agraf@suse.de> <20140508013325.GA5474@amt.cnet> In-Reply-To: <20140508013325.GA5474@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 08.05.14 03:33, Marcelo Tosatti wrote: > 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. However, I've seen cases where the kvmclock guest structure >> indicates a time more recent than the kvm returned time. >> >> To make sure we never go backwards, calculate what the guest would have seen >> as time at the point of migration and use that value instead of the kernel >> returned one when it's more recent. >> >> While this doesn't fix the underlying issue that the kernel's view of time >> is skewed, it allows us to safely migrate guests even from sources that are >> known broken. >> >> Signed-off-by: Alexander Graf > OK Alexander better move this logic to the kernel, in KVM_GET_CLOCK. > > Otherwise every user of KVM_GET_CLOCK would have to apply the > workaround. Well, the breakage occurs on the *source* of things. So if I have 100 VMs running, I'm pretty sure one of them gets hit by this bug. If I put the workaround in the kernel, I have to take the chance to break some of those 100 VMs to get things rolling. If I put it in QEMU, I can live with a broken migration source. This gets even worse when you want to phase out unfixed host kernels. Alex