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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Please forget this one, since original logic looks correct.

Thanks,
Kevin 

>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
>like:
>
>- 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.
>
>Thanks,
>Kevin
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel