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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.02.17 at 11:27, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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.

Jan


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