[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Rik van Riel" <riel@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 7 Aug 2008 10:01:24 +0800
  • Cc:
  • Delivery-date: Wed, 06 Aug 2008 19:01:53 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.