RE: [Xen-devel] [PATCH] Adjust time init sequence

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

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Friday, December 12, 2008 6:38 PM
>
>On 12/12/2008 10:10, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>>> How about rdtscll(t->local_tsc_stamp) at the top of 
>init_xen_time(), and
>>> remove the one I added to early_time_init()? That would 
>allow NOW() usage at
>>> least in init_xen_time(), and be later than the TSC reset.
>> 
>> Perhaps it should be considered to switch to the non-resetting
>> synchronization logic in x86-64 Linux up to 2.6.20 (according to the
>> comments there derived from ia64), or even the current version that
>> doesn't re-write the TSC at all?
>
>Quite agreeable, albeit a bigger patch. ;-)
>

Current Linux doesn't re-write TSC but marking it as unstable
and then may use alternative source if available. For Xen, tsc is 
one basic wheel to drive both pv and hvm time virtualization. By
not re-writing TSCs on those platforms with unsynchrozed TSC,
it may cause time issue since currently hvm guest doesn't adjust
guest TSC offset across vcpu migration. Then if above change is
pursued, first we'd better add guest TSC offset adjustment to 
avoid cause regression on those platforms?

Also do you know the reason why Linux doesn't re-write TSC
nowadays? I recalled some thread seen before that such re-write
may cause time warp on some platforms, but not sure about the
detail. Did we ever see similar issue caused by re-write in Xen
before?

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