On 03/06/2007 04:24 PM, Jeremy Fitzhardinge wrote:

Thomas Gleixner wrote:

quoted

quoted

3) clockevent set_next_event interface is suboptimal for paravirt (and 
probably realtime-ish uses).  The problem is that the expiry is passed 
as a relative time.  On paravirt, an arbitrary amount of (stolen) time 
may have passed since the delta was computed and when the timer device 
is programmed, causing that next interrupt to be too far out in the 
future.  It seems a better interface for set_next_event would be to pass 
the current time and the absolute expiry.  Actually, I sent email to 
Thomas and Ingo about this (and some other clockevents/hrtimer feedback) 
in July 2006, but never heard back.  Thoughts?
    

There is no problem for realtime uses, as the reprogramming path is
running with local interrupts disabled. I can see the point for paravirt
and I'm not opposed to change / expand the interface for that. It might
be done by an extra clockevents feature flag, which requests absolute
time instead of relative time.
  

I'm not sure how much different it makes overall.  It's true that
absolute time would be a more useful interface, but because the guest
vcpu can be preempted at any time, we could miss the timeout
regardless.  In Xen if you set a timeout for the past you get an
immediate interrupt; I presume the clockevent code can deal with that?

That's the problem though, you won't know to set it for the past since 
the expiry is relative.  When the vcpu starts running again, it will set 
the timer to expire X ns from now, not Xns from when the timer was 
requested.