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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.16 at 13:35, <andrew.cooper3@xxxxxxxxxx> wrote:
> Once we have ever had cause to use time_calibration_tsc_rendezvous,
> there is no situation where it is safe to switch back to
> time_calibration_std_rendezvous, as the choice to use
> time_calibration_tsc_rendezvous means the TSCs aren't in sync, and Xen
> has no practical mechanism to resync them.  (We could guarantee not to
> ever invoke Cstates, including C1E, but this doesn't prevent an SMI
> doing that for us.)

Okay, I think I'm finally following you. Yet ...

> time_calibration_rendezvous_fn should start with the best case scenario,
> and be gradually made worse by our AP discovery, but should never get
> better.

... that's already the case with the patch: CONSTANT_TSC can only
be cleared by command line option (i.e. before any of this code runs)
or in tsc_check_writability() (which runs before clear_tsc_cap() gets
invoked first). Hence the possibility of switching back from tsc to std
depends solely on TSC_RELIABLE potentially getting set during/after
AP bringup. Yet that never happens, we only ever clear that flag
(which is part of the purpose of clear_tsc_cap()).

Bottom line - I don't see how you think we may end up switching back
from tsc to std. Perhaps it is then all just a matter of changing a few
names and/or adding a BUG_ON() or panic() to make things more clear
to you and possible other readers?

Jan


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