From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [QEMU PATCH v2] kvmclock: advance clock by time window between vm_stop and pre_save Date: Mon, 7 Nov 2016 22:06:09 -0200 Message-ID: <20161108000609.GA3689@amt.cnet> References: <20161104094322.GA16930@amt.cnet> <20161104165933.GA3027@amt.cnet> <20161107154610.GG2054@work-vm> <20161107194058.GB28327@amt.cnet> <20161107200349.GC1155@work-vm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eduardo Habkost , kvm@vger.kernel.org, Juan Quintela , Radim =?utf-8?B?S3LEjW3DocWZ?= , qemu-devel , Paolo Bonzini To: "Dr. David Alan Gilbert" Return-path: Content-Disposition: inline In-Reply-To: <20161107200349.GC1155@work-vm> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On Mon, Nov 07, 2016 at 08:03:50PM +0000, Dr. David Alan Gilbert wrote: > * Marcelo Tosatti (mtosatti@redhat.com) wrote: > > On Mon, Nov 07, 2016 at 03:46:11PM +0000, Dr. David Alan Gilbert wrote: > > > * Marcelo Tosatti (mtosatti@redhat.com) wrote: > > > > This patch, relative to pre-copy migration codepath, > > > > measures the time between vm_stop() and pre_save(), > > > > which includes copying the remaining RAM to destination, > > > > and advances the clock by that amount. > > > > > > > > In a VM with 5 seconds downtime, this reduces the guest > > > > clock difference on destination from 5s to 0.2s. > > > > > > > > Tested with Linux and Windows 2012 R2 guests with -cpu XXX,+hv-time. > > > > > > One thing that bothers me is that it's only this clock that's > > > getting corrected; doesn't it cause things to get upset when > > > one clock moves and the others dont? > > > > If you are correlating the clocks, then yes. > > > > Older Linux guests get upset (marking the TSC clocksource unstable > > because the watchdog checks TSC vs kvmclock), but there is a workaround for it > > in newer guests > > (kvmclock interface to notify watchdog to not complain). > > > > Note marking TSC clocksource unstable on older guests is harmless > > because kvmclock is the standard clocksource. > > > > For Windows guests, i don't know that Windows correlates between different > > clocks. > > > > That is, there is relative control as to which software reads kvmclock > > or Windows TIMER MSR, so i don't see the need to advance every clock > > exposed. > > > > > Shouldn't the pause delay be recorded somewhere architecturally > > > independent and then be a thing that kvm-clock happens to use and > > > other clocks might as well? > > > > In theory, yes. In practice, i don't see the need for this... > > It seems unlikely to me that x86 is the only one that will want > to do something similar. Can't they copy what kvmclock is doing today? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3u6j-0008Mf-MQ for qemu-devel@nongnu.org; Mon, 07 Nov 2016 19:17:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3u6f-0005CG-MY for qemu-devel@nongnu.org; Mon, 07 Nov 2016 19:17:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59790) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c3u6f-0005C3-H4 for qemu-devel@nongnu.org; Mon, 07 Nov 2016 19:17:41 -0500 Date: Mon, 7 Nov 2016 22:06:09 -0200 From: Marcelo Tosatti Message-ID: <20161108000609.GA3689@amt.cnet> References: <20161104094322.GA16930@amt.cnet> <20161104165933.GA3027@amt.cnet> <20161107154610.GG2054@work-vm> <20161107194058.GB28327@amt.cnet> <20161107200349.GC1155@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161107200349.GC1155@work-vm> Subject: Re: [Qemu-devel] [QEMU PATCH v2] kvmclock: advance clock by time window between vm_stop and pre_save List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: kvm@vger.kernel.org, qemu-devel , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Juan Quintela , Eduardo Habkost On Mon, Nov 07, 2016 at 08:03:50PM +0000, Dr. David Alan Gilbert wrote: > * Marcelo Tosatti (mtosatti@redhat.com) wrote: > > On Mon, Nov 07, 2016 at 03:46:11PM +0000, Dr. David Alan Gilbert wrote: > > > * Marcelo Tosatti (mtosatti@redhat.com) wrote: > > > > This patch, relative to pre-copy migration codepath, > > > > measures the time between vm_stop() and pre_save(), > > > > which includes copying the remaining RAM to destination, > > > > and advances the clock by that amount. > > > > > > > > In a VM with 5 seconds downtime, this reduces the guest > > > > clock difference on destination from 5s to 0.2s. > > > > > > > > Tested with Linux and Windows 2012 R2 guests with -cpu XXX,+hv-time. > > > > > > One thing that bothers me is that it's only this clock that's > > > getting corrected; doesn't it cause things to get upset when > > > one clock moves and the others dont? > > > > If you are correlating the clocks, then yes. > > > > Older Linux guests get upset (marking the TSC clocksource unstable > > because the watchdog checks TSC vs kvmclock), but there is a workaround for it > > in newer guests > > (kvmclock interface to notify watchdog to not complain). > > > > Note marking TSC clocksource unstable on older guests is harmless > > because kvmclock is the standard clocksource. > > > > For Windows guests, i don't know that Windows correlates between different > > clocks. > > > > That is, there is relative control as to which software reads kvmclock > > or Windows TIMER MSR, so i don't see the need to advance every clock > > exposed. > > > > > Shouldn't the pause delay be recorded somewhere architecturally > > > independent and then be a thing that kvm-clock happens to use and > > > other clocks might as well? > > > > In theory, yes. In practice, i don't see the need for this... > > It seems unlikely to me that x86 is the only one that will want > to do something similar. Can't they copy what kvmclock is doing today?