This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [BUG 1282] time jump on live migrate root cause &propose

To: "Rik van Riel" <riel@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [BUG 1282] time jump on live migrate root cause &proposed fixes
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 7 Aug 2008 10:01:24 +0800
Delivery-date: Wed, 06 Aug 2008 19:01:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080806164657.647bc167@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080806164657.647bc167@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acj4BaGw7GAVV0zFTGChxrM4juKneQAIkz6g
Thread-topic: [Xen-devel] [BUG 1282] time jump on live migrate root cause &proposed fixes
>From: Rik van Riel
>Sent: 2008年8月7日 4:47
>I can think of a few possible fixes for this issue:
>1) have system_time in the hypervisor start at unix epoch 0
>   (january 1st 1970) instead of at boot time - this may
>   require some magic to sync_cmos_clock(), sync_xen_wallclock()
>   and/or other functions so dom0 does not get too confused while
>   changing the time during bootup

This looks good, with only concern on compability. Would it 
cause messed time in all old domUs even for normal running, 
when fixing the issue related to special case like migration?

>2) have time_init() and time_resume() calculate the hypervisor
>   boot time from the shared_info ->wc_sec ->wc_nsec and the
>   shared_info->per cpu vcpu_info->system_time -- if the host
>   boot time changes (by more than a second?) adjust some local
>   offset that we add into get_nsec_offset() and get_usec_offset()
>   to always adjust the time right

There may be issue. Although xen implementes system_time as
elapsed cycles since boot, wc_sec is not a static value stamped
at boot time. For any reason when xen is requested to change
wall clock (do_settime), xen adjusts wc_sec while keeping 
system_time intact. (wc_sec + system_time = wall clock). That
says, even on same machine shared_info->wc_xxx is variable.
So it'd be difficult for domU to calculate boot time directly from
shared info page.

The key point is that Xen simply aligns all domU's system time
to xen's system time, regardless of when domU is created. Then
one alternative is to introduce a per-domain system time concept

- At time_init, reset processed_system_time to zero and record
offset to xen's system time. Some interfaces needs a bit changes
to understand this offset.

- Add a time_suspend, which saves wall clock time (xtime?) at
that time

- Then in time_resume, retrieve current wall clock time from shared
info page, and then compared to the value recorded at suspend
time. The delta is then reflected to processed_system_time, with
offset adjusted according to new wc_xxx and xen system_time.

One caution is about time zone difference, which however can be 
compensated by control panel to ensure comparison in 
time_resume is made meaningfullly.


Xen-devel mailing list