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> > --- > 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? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
