From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v3 04/13] x86/time.c: Scale host TSC in pvclock properly Date: Tue, 5 Jan 2016 11:15:07 -0500 Message-ID: <568BEC0B.3020209@oracle.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160105005937.GB3619@hz-desktop.sh.intel.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: xen-devel@lists.xen.org, Jan Beulich , Kevin Tian , Keir Fraser , Andrew Cooper , Suravee Suthikulpanit , Aravind Gopalakrishnan , Jun Nakajima List-Id: xen-devel@lists.xenproject.org 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?). 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;