From mboxrd@z Thu Jan 1 00:00:00 1970 From: Haozhong Zhang Subject: Re: [PATCH v3 04/13] x86/time.c: Scale host TSC in pvclock properly Date: Wed, 6 Jan 2016 08:56:51 +0800 Message-ID: <20160106005651.GH3619@hz-desktop.sh.intel.com> References: <1451531020-29964-1-git-send-email-haozhong.zhang@intel.com> <1451531020-29964-5-git-send-email-haozhong.zhang@intel.com> <568AB575.7090608@oracle.com> <20160105005937.GB3619@hz-desktop.sh.intel.com> <568BEC0B.3020209@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <568BEC0B.3020209@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: Kevin Tian , Keir Fraser , Jan Beulich , Jun Nakajima , Andrew Cooper , xen-devel@lists.xen.org, Aravind Gopalakrishnan , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org On 01/05/16 11:15, Boris Ostrovsky wrote: > On 01/04/2016 07:59 PM, Haozhong Zhang wrote: > >On 01/04/16 13:09, Boris Ostrovsky wrote: > >>On 12/30/2015 10:03 PM, Haozhong Zhang wrote: > >>>This patch makes the pvclock return the scaled host TSC and > >>>corresponding scaling parameters to HVM domains if guest TSC is not > >>>emulated and TSC scaling is enabled. > >>> > >>>Signed-off-by: Haozhong Zhang > >>>--- > >>>Changes in v3: > >>> (addressing Boris Ostrovsky's comments) > >>> * No changes in fact. tsc_set_info() does not set d->arch.vtsc to 0 > >>> if host_tsc_is_safe() is not satisfied, so it is safe to use > >>> d->arch.vtsc_to_ns here. > >>I don't think I understand your argument here. I think last time we decided > >>that vtsc_to_ns can be used only if TSC is constant. > >> > >>-boris > >> > >In tsc_set_info(), if TSC scaling is available and host has > >X86_FEATURE_TSC_RELIABLE (checked by host_tsc_is_safe()), vtsc is left > >to 0. And looking at init_amd() and init_intel(), > >X86_FEATURE_CONSTANT_TSC is available whenever > >X86_FEATURE_TSC_RELIABLE is available as well. Therefore, when > >vtsc_to_ns is used in __update_vcpu_system_time(), we can always > >ensure that host has X86_FEATURE_CONSTANT_TSC and do not need to > >recheck it there. > > OK --- I was looking at tsc_set_info()'s TSC_MODE_NEVER_EMULATE path but now > I realize that we don't use scaling in that mode (right?). > Right. Haozhong > Reviewed-by: Boris Ostrovsky > > > > > >Haozhong > > > >>> xen/arch/x86/time.c | 16 ++++++++++++---- > >>> 1 file changed, 12 insertions(+), 4 deletions(-) > >>> > >>>diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > >>>index d83f068..b31634a 100644 > >>>--- a/xen/arch/x86/time.c > >>>+++ b/xen/arch/x86/time.c > >>>@@ -815,10 +815,18 @@ static void __update_vcpu_system_time(struct vcpu *v, int force) > >>> } > >>> else > >>> { > >>>- tsc_stamp = t->local_tsc_stamp; > >>>- > >>>- _u.tsc_to_system_mul = t->tsc_scale.mul_frac; > >>>- _u.tsc_shift = (s8)t->tsc_scale.shift; > >>>+ if ( has_hvm_container_domain(d) && cpu_has_tsc_ratio ) > >>>+ { > >>>+ tsc_stamp = hvm_funcs.scale_tsc(v, t->local_tsc_stamp); > >>>+ _u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac; > >>>+ _u.tsc_shift = d->arch.vtsc_to_ns.shift; > >>>+ } > >>>+ else > >>>+ { > >>>+ tsc_stamp = t->local_tsc_stamp; > >>>+ _u.tsc_to_system_mul = t->tsc_scale.mul_frac; > >>>+ _u.tsc_shift = (s8)t->tsc_scale.shift; > >>>+ } > >>> } > >>> _u.tsc_timestamp = tsc_stamp; > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel