Re: [PATCH v3] x86/time: correctly honor late clearing of TSC related feature flags

[Joao Martins <joao.m.martins@oracle.com>]

On 02/07/2017 10:47 AM, Jan Beulich wrote:
>>>> On 07.02.17 at 11:27, <andrew.cooper3@citrix.com> wrote:
>> On 06/02/17 08:39, Jan Beulich wrote:
>>> As such clearing of flags may have an impact on the selected rendezvous
>>> function, defer the establishing of a rendezvous function other than
>>> the initial default one (std) until after all APs have been brought up.
>>>
>>> But don't allow such feature flags to be cleared during CPU hotplug:
>>> Platform and local system times may have diverged significantly by
>>> then, potentially causing noticeably (even if only temporary) strange
>>> behavior. As we're anyway expecting only sufficiently similar CPUs to
>>> appear during hotplug, this shouldn't be introducing new limitations.
>>>
>>> Reported-by: Joao Martins <joao.m.martins@oracle.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Thanks.
> 
>>> ---
>>> v3: Drop original approach entirely - defer everything to
>>>     verify_tsc_reliability(), making for quite a bit smaller a patch.
>>>
>>> Note: Considering that tsc_check_writability() checks
>>>       TSC_RELIABLE, it being run before that feature flag has obtained
>>>       its final value seems problematic too. Should we defer that call
>>>       too?
>>
>> Do we know which CPUs this applies to?  Might we be safe by being only
>> 64bit these days?
> 
> amd.c sets it when ITSC and model != 0x11, which I think includes
> 64-bit CPUs. intel.c sets it unconditionally when ITSC. However, I
> don't see how all this matters, as we clear it as the result of the
> TSC warp producing a non-zero tsc_max_warp, and that check is
> purely a software thing.

Considering that TSC_RELIABLE bit (or the lack of it) is only truly valid after
tsc reliability checks have been done, then it probably makes sense to move the
writability check after verify_tsc_reliability (or at the end of it) one as you
seem to hint above.

Joao

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