From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] Adjust time init sequence Date: Fri, 12 Dec 2008 09:08:30 +0000 Message-ID: References: <0A882F4D99BBF6449D58E61AAFD7EDD603BB493B@pdsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0A882F4D99BBF6449D58E61AAFD7EDD603BB493B@pdsmsx502.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 12/12/2008 03:40, "Tian, Kevin" wrote: > 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? :-) 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. -- Keir