From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: Re: [PATCH][v4] PV extension of HVM(hybrid) support in Xen Date: Tue, 2 Mar 2010 13:04:17 +0800 Message-ID: <201003021304.17595.sheng@linux.intel.com> References: <201003011743.41341.sheng@linux.intel.com> <201003021136.02590.sheng@linux.intel.com> <4B8C9686.40608@goop.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B8C9686.40608@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Ian Campbell , Ian Pratt , xen-devel , Tim Deegan , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Tuesday 02 March 2010 12:39:34 Jeremy Fitzhardinge wrote: > 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. > Sorry, I misunderstood. HVM assume it start from 0... PV is following the native. We set the offset to 0, so that PV tsc is the same as native. -- regards Yang, Sheng