[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] Adjust time init sequence
>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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |