From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 1/5] Add a global synchronization point for pvclock Date: Tue, 26 Oct 2010 10:04:38 -0700 Message-ID: <4CC70A26.2090200@goop.org> References: <1271356648-5108-1-git-send-email-glommer@redhat.com> <1271356648-5108-2-git-send-email-glommer@redhat.com> <4CC6130B.8020908@goop.org> <4CC68DE1.1060604@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Glauber Costa , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marcelo Tosatti , Zachary Amsden , "Xen-devel@lists.xensource.com" To: Avi Kivity Return-path: In-Reply-To: <4CC68DE1.1060604@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 10/26/2010 01:14 AM, Avi Kivity wrote: > On 10/26/2010 01:30 AM, Jeremy Fitzhardinge wrote: >> Unfortunately this is breaking Xen save/restore: if you restore on a >> host which was booted more recently than the save host, causing the >> system time to be smaller. The effect is that the domain's time leaps >> forward to a fixed point, and stays there until the host catches up to >> the source host... > > Shouldn't save/restore also save the timebase? Xen doesn't guarantee the system time is monotonic across those kinds of events. The domain could maintain its own offset to maintain an illusion of monotonicity, but I think its simpler to just zero last_value on resume. J