Re: [Xen-devel] [PATCH v2 06/14] x86/time.c: Scale host TSC in pvclock properly

[Joao Martins <joao.m.martins@xxxxxxxxxx>]

On 12/10/2015 11:56 AM, Joao Martins wrote:
> 
> 
> On 12/10/2015 12:23 AM, Haozhong Zhang wrote:
>> On 12/08/15 14:21, Boris Ostrovsky wrote:
>>> On 12/07/2015 08:52 PM, Haozhong Zhang wrote:
>>>> On 12/07/15 13:14, Boris Ostrovsky wrote:
>>>>> On 12/06/2015 03:58 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>
>>>>> +Joao who has been staring at this code.
>>>>>
> Apologies for late response but I was out in the beginning of the week and was
> still catching up.
> 
>>>>> Joao, can you run this series through your test with non-native frequency?
>>>>> (http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg00683.html
>>>>> provides an interface to set it in config file).
>>>>>
> OK, I will run it through my time warp tests.
I have using these for a while now and so far I got no issues with a non-native
frequency [I don't have a Skylake processor in my possession to test it
natively]. In addition I rebased my vdso tests on top of your series and no
warps too. But will raise out any flags if I found anything wrong.

> 
>>>>>
>>>>>> ---
>>>>>>  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 95df4f1..732d1e9 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 ( is_hvm_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;
>>>>> I am not sure this is correct (which is why I asked Joao to look at this 
>>>>> and
>>>>> test). The scaler below is calculated as result of TSC calibration across
>>>>> physical CPUs and what you use above (vtsc_to_ns) is an uncalibrated 
>>>>> value.
>>>>>
>>>> Because guest TSC is synchronized among all vcpus of a domain, I think
>>>> it's safe to use d->arch.vtsc_to_ns here.
>>>
>>> This is only guaranteed if we have constant/reliable TSC. So perhaps you
>>> should set tsc_scaling_supported only when either (or both?) of these TSC
>>> properties are true. Which is probably the case anyway but may be worth
>>> explicitly checking in start_svm/vmx?
>>
>> Yes, I'll add the additional check in the next version.
>>
> I believe constant TSC to be the only feature that is checked on
> local_time_calibration.
> 
>>> (and use tsc_scaling_supported instead
>>> of cpu_has_tsc_ratio in the 'if' statement)
>>
>> This one is only for bug fix, so tsc_scaling_supported has not been
>> introduced. Patch 8 introduces tsc_scaling_supported and patch 12
>> replaces all cpu_has_tsc_ratio with it.
>>
>>>
>>> And just like I asked in the previous email --- should we then use the same
>>> scaler (which would be vtsc_to_ns) in both cases? At least for guests in HVM
>>> containers (it may work for PV guests as well, but it would need to be
>>> confirmed).
>>>
>> Yes, but I'll check PV code first.
>>
>>> Also, I noticed that this routine uses is_hvm_domain(). I think it should be
>>> has_hvm_container_domain().
>>>
>> forgot updating here, will do in the next version.
>>
>> Haozhong
>>
>> _______________________________________________
>> 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