Re: [Xen-devel] [PATCH] x86/time: Don't use virtual TSC if host and guest frequencies are equal

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.03.17 at 13:44, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 03/16/2017 06:40 AM, Jan Beulich wrote:
>>>>> On 15.03.17 at 20:48, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -2051,17 +2051,11 @@ void tsc_set_info(struct domain *d,
>>>          d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
>>>          d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
>>>          set_time_scale(&d->arch.vtsc_to_ns, d->arch.tsc_khz * 1000);
>>> -        /*
>>> -         * In default mode use native TSC if the host has safe TSC and:
>>> -         *  HVM/PVH: host and guest frequencies are the same (either
>>> -         *           "naturally" or via TSC scaling)
>>> -         *  PV: guest has not migrated yet (and thus arch.tsc_khz == 
>>> cpu_khz)
>>> -         */
>>> +
>>>          if ( tsc_mode == TSC_MODE_DEFAULT && host_tsc_is_safe() &&
>>> -             (has_hvm_container_domain(d) ?
>>> -              (d->arch.tsc_khz == cpu_khz ||
>>> -               hvm_get_tsc_scaling_ratio(d->arch.tsc_khz)) :
>>> -              incarnation == 0) )
>>> +             (d->arch.tsc_khz == cpu_khz || incarnation == 0 ||
>> Is the incarnation comparison really needed here, i.e. doesn't it
>> being zero imply the two frequencies to match in default mode?
> 
> It is not necessary but I wanted to keep it for clarity so that it is
> explicit that when a domain is born we don't use vtsc.

Well, considering the history here, I think its presence is rather
going to raise questions than to answer any, so if anything I'd
suggest to have an ASSERT() to that effect, at once serving as
sort of documentation. But I may be the only one thinking this
way ...

Jan


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