From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [PATCH][v4] PV extension of HVM(hybrid) support in Xen Date: Mon, 01 Mar 2010 20:39:34 -0800 Message-ID: <4B8C9686.40608@goop.org> References: <201003011743.41341.sheng@linux.intel.com> <201003011940.50685.sheng@linux.intel.com> <4B8C6EC3.2020307@goop.org> <201003021136.02590.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201003021136.02590.sheng@linux.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: Sheng Yang Cc: Ian Campbell , Ian Pratt , xen-devel , Tim Deegan , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 03/01/2010 07:36 PM, Sheng Yang wrote: >> static u64 pvclock_get_nsec_offset(struct pvclock_shadow_time *shadow) >> { >> u64 delta = native_read_tsc() - shadow->tsc_timestamp; >> return scale_delta(delta, shadow->tsc_to_nsec_mul, shadow- >> tsc_shift); >> } >> > tsc_timestamp take the vcpu beginning at 0, so that's the assumption. Why would it be 0? Xen sets tsc_timestamp to the current tsc when it updates the time parameters, which is whenever the vcpu is scheduled on a pcpu (and other times). There's no expectation that the tsc starts from 0, since that won't ever be the case. J