[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/8] x86/time: correctly honor late clearing of TSC related feature flags
On 04/07/16 16:53, Jan Beulich wrote: >>>> On 04.07.16 at 17:39, <andrew.cooper3@xxxxxxxxxx> wrote: >> On 20/06/16 16:20, Jan Beulich wrote: >>>>>> On 20.06.16 at 16:32, <andrew.cooper3@xxxxxxxxxx> wrote: >>>> On 15/06/16 11:28, Jan Beulich wrote: >>>>> --- a/xen/arch/x86/time.c >>>>> +++ b/xen/arch/x86/time.c >>>>> @@ -1358,6 +1358,24 @@ static void time_calibration(void *unuse >>>>> &r, 1); >>>>> } >>>>> >>>>> +void __init clear_tsc_cap(unsigned int feature) >>>>> +{ >>>>> + void (*rendezvous_fn)(void *) = time_calibration_std_rendezvous; >>>> This should read time_calibration_rendezvous_fn rather than assuming >>>> time_calibration_std_rendezvous. >>>> >>>> Otherwise, there is a risk that it could be reset back to >>>> time_calibration_std_rendezvous. >>> But that's the purpose: We may need to switch back. >> Under what circumstances could we ever move from re-syncing back to not >> re-syncing? > verify_tsc_reliability() may result in X86_FEATURE_TSC_RELIABLE > getting cleared. That's an initcall, which means it runs after > init_xen_time(), and hence after the rendezvous function got > established initially. Right, but that isn't important. There will never be a case where, once TSC_RELIABLE is cleared, it is safe to revert back to std_rendezvous, even if TSC_RELIABLE is subsequently re-set. Therefore, this function must never accidentally revert time_calibration_rendezvous_fn from time_calibration_tsc_rendezvous back to time_calibration_std_rendezvous. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |