RE: [Xen-devel] [PATCH 0/2] range timer support

["Yu, Ke" <ke.yu@xxxxxxxxx>]

Dan Magenheimer wrote:
>> here is my two cents just for your reference. I have tried range
>> timer in several places: <snip>
>> - HVM virtual period timer: this timer allow expires behind deadline
>> a bit, because it has logic to handling missing ticks. so the range
>> can be [deadline, deadline + period/n]. to be more conservative, it
>> is safe to add up limit of 1ms. the 1ms comes from the commodity OS
>> frequency, e.g. Linux kernel has 1000/250/100 HZ, and windows has 64
>> HZ, 1ms should meet the up limit of 1000HZ.
> 
> A reminder that hvm HPET usage by some Linux kernels has a
> problem where delivery of a tick sooner than expected can
> cause the guests apparent time to advance too quickly.
> Dave Winchell submitted a patch for this some time back
> that didn't get accepted (for various reasons) and I'm
> not sure if this range timer implementation will make it
> better or worse.
> 
> But I'm pretty sure that if ticks are delivered at:
> 
> T+0d+3s, T+1d+2s, T+2d+1s
> 
> where d=1/Hz and s=slop, the problem will be observed.
> 
> Dave, can you comment?
> 
> Dan

In the range-timer-use.patch, vpt timer range is [deadline, deadline+ 
MIN(period/8, 1ms)], so the tick will only expire later than expected, thus 
will not trigger the issue you mentioned. Anyway, range timer is just API, 
caller has the flexibility to decide how to use it. in the HPET case, since we 
know HPET does not allow early ticks, we can dedicatedly set range to avoid 
that.

If we increasing TIME_SLOP value, HPET ticks may expires sooner than expected. 

Best Regards
Ke




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel