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 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.

>>>>
>>>>> ---
>>>>>  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