Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.04.16 at 16:56, <joao.m.martins@xxxxxxxxxx> wrote:
> On 04/05/2016 11:43 AM, Jan Beulich wrote:
>>>>> On 29.03.16 at 15:44, <joao.m.martins@xxxxxxxxxx> wrote:
>>> @@ -541,6 +613,10 @@ static int __init try_platform_timer(struct 
>>> platform_timesource *pts)
>>>      if ( rc <= 0 )
>>>          return rc;
>>>  
>>> +    /* We have a platform timesource already so reset it */
>>> +    if ( plt_src.counter_bits != 0 )
>>> +        reset_platform_timer();
>> 
>> What if any of the time functions get used between here and the
>> setting of the new clock source? For example, what will happen to
>> log messages when "console_timestamps=..." is in effect?
> time functions will use NOW() (i.e. get_s_time) which uses cpu_time structs
> being updated on local_time_calibration() or cpu frequency changes.
> reset_platform_timer() will zero out some of the variables used by the
> plt_overflow and read_platform_stime(). The overflow and calibration isn't an
> issue as the timers are previously killed so any further calls will use what's
> on cpu_time while plt_src is being changed.
> 
> The case I could see this being different is if cpu_frequency_change is called
> between reset_platform_time() and the next update of stime_platform_stamp. In
> this situation the calculation would end up a bit different meaning subsequent
> calls of read_platform_stime() would return the equivalent to
> scale_delta(plt_src->read_counter(), plt_scale), as opposed to computing with 
> a
> previous taken stime_platform_stamp and incrementing a difference with a 
> counter
> read. But can this situation actually happen?

No matter which CPU freq model is being used (right now, may
change when the Intel P-state driver finally arrives), Dom0 is
required to be executing already, so no issue here.

Since you didn't go into any detail on the specific example of log
time stamps - am I to imply that they're completely unaffected by
this (i.e. there's also no risk of them going backwards for a brief
period of time)?

Jan


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