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

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

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Thursday, December 11, 2008 9:12 PM
>
>On 11/12/2008 09:04, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
>> By the way, instead of avoiding NOW() early on, could we just set
>> local_tsc_stamp in early_time_init()? Then we could use NOW() when
>> initialising idle VCPUs, and also early on in init_xen_time()?
>> 
>> We could set stime_platform_stamp = NOW() too, so that 
>platform time is
>> kicked off following BP's time.
>> 
>> I could send a patch which I find tasteful if you think this 
>could work? :-)
>
>It turned out pretty simple, so I checked it in as c/s 18909. 
>Let me know
>how that works for you.
>

Unfortunately it doesn't work, and gave me a TOD to year 2185.
After checking the code, record tsc stamp in early time init
is nullified by later synchronize_tsc_bp which reset TSC to zero.
Then later invocation to get_s_time gets a negative value which
is converted to an extremely large system time.

A temp workaround is to move rdtscll(t->local_tsc_stamp) into
calibrate_tsc_bp, which gives a sane NOW() before percpu time
init. But then the purpose behind is ambiguous... why would we
want to count system time from this point? If we can't count 
system time starting from power on, it looks clearer to tag system 
time as 0 when initializing wc_sec/wc_nsec by do_settime. 
Actually the starting point of xen system time is not that critical
since it's mostly used by relative progress. Then my previous 
updated patch can be used? :-)

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