Re: [Qemu-devel] Rethinking missed tick catchup

[Anthony Liguori <anthony@codemonkey.ws>]

Gleb Natapov <gleb@redhat.com> writes:

>> That's a bug.
>> 
>> The next period calculation should not be based on the last period +
>> length of period but rather on the current time + delta to next period
>> boundary.
>> 
> I disagree that this is a bug. This is by design to account for timer
> signals that was delivered to late.

It's immediate reinjection of ticks missed due to timer delay such that
even if you select tdf=slew, you're still doing reinject.

Maybe it's just semantics of whether it's a bug or feature, but
hopefully you agree that making tdf=slew gradually deliver those missed
ticks would be a good thing.

>
>
>> IOW, if we shouldn't arm timers to expire backwards in time from when
>> the event occurred.  That should be accounted as a missed tick.
>> 
> Not all users of qemu_timer have their own missed tick accounting so
> qemu_timer provides general one. We can create another time source
> for qemu_timer without this behaviour and use it in RTC.

I think we probably should start by getting one device to have good
catchup behavior and then we can look at generalizing.

There are other things we've never done that would help too (like
allowing for non-base 10 timer frequencies) that would make some of the
time calculations easier.

But I think at this point, I need to send some patches which requires
some hacking first..

Regards,

Anthony Liguori

>
>
> --
> 			Gleb.