[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 04/13] x86/time.c: Scale host TSC in pvclock properly



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 <haozhong.zhang@xxxxxxxxx>
> >>>---
> >>>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 <boris.ostrovsky@xxxxxxxxxx>
> 
> 
> >
> >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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.