>>> On 07.02.17 at 11:27, <andrew.coop...@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.mart...@oracle.com> >> Signed-off-by: Jan Beulich <jbeul...@suse.com> > > Acked-by: Andrew Cooper <andrew.coop...@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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
