[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3] x86/time: correctly honor late clearing of TSC related feature flags
On 02/07/2017 10:47 AM, Jan Beulich wrote: >>>> 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. 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |