Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Avi Kivity <avi@redhat.com>]

On 02/07/2011 05:14 PM, Jan Kiszka wrote:
> On 2011-02-07 16:08, Avi Kivity wrote:
> >  On 02/07/2011 05:01 PM, Jan Kiszka wrote:
> >>>
> >>>   On the other hand, we need a way to inject lost ticks into a
> >>>   PeriodicTimer.  If interrupt injection detects that an interrupt was
> >>>   coalesced, we want the timer to schedule a new tick for us.
> >>
> >>  Isn't absence of corresponding call to periodic_timer_ack() sufficient?
> >
> >  It probably is.  However, that API is easy to misuse; if you forget to
> >  call it, the timer goes crazy.  The default behaviour should be to
> >  assume an ack and the API should provide adjustments.
>
> Explicit nack'ing only works smoothly if we have immediate (synchronous)
> feedback about the injected event. My feeling is that ack'ing results in
> simpler, thus also easier to review code.

Yes.  Maybe we should have an auto-ack mode, so that code that doesn't 
have ack notification doesn't need to bother with it.

> >
> >  Also need to design the API carefully for changing frequency (Windows is
> >  known to do that) and switching from periodic to single shot.  For the
> >  first case I guess we need to adjust the deferred ticks to the new time
> >  base (so if the frequency doubles, the lost ticks up to that point
> >  double as well).  For the second case, I guess we just lose time.
>
> I think this is rather a question how the logic behind
> periodic_timer_mod works with updates. The API should be sufficient as
> simple as it is.

Yes, it's an implementation detail.

-- 
error compiling committee.c: too many arguments to function