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&proposed

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "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:23:06 +0800
Delivery-date: Wed, 06 Aug 2008 19:23:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D9661@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <D470B4E54465E3469E2ABBC5AFAC390F024D9661@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acj4BaGw7GAVV0zFTGChxrM4juKneQAIkz6gAAMc4gA=
Thread-topic: [Xen-devel] [BUG 1282] time jump on live migrate root cause&proposed fixes
Please forget this one, since original logic looks correct.


>From: Tian, Kevin
>Sent: 2008年8月7日 10:01
>>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

Xen-devel mailing list