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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/01/17 14:42, Jan Beulich wrote:
>>>> 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?

My concern is what happens if some code plays with the feature flags,
then re-calls clear_tsc_cap()

With your proposal, this will be unsafe as it loads the wrong rendezvous
function.

With my proposal, there is no amount of playing with feature flags and
recalling clear_tsc_cap() which can end up reverting to a weaker
rendezvous function.

~Andrew

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