Re: [Qemu-devel] Rethinking missed tick catchup

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 12 Sep 2012 08:54:26 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> 
> Hi,
> 
> We've been running into a lot of problems lately with Windows guests and
> I think they all ultimately could be addressed by revisiting the missed
> tick catchup algorithms that we use.  Mike and I spent a while talking
> about it yesterday and I wanted to take the discussion to the list to
> get some additional input.
> 
> Here are the problems we're seeing:
> 
> 1) Rapid reinjection can lead to time moving faster for short bursts of
>    time.  We've seen a number of RTC watchdog BSoDs and it's possible
>    that at least one cause is reinjection speed.
> 
> 2) When hibernating a host system, the guest gets is essentially paused
>    for a long period of time.  This results in a very large tick catchup
>    while also resulting in a large skew in guest time.
> 
>    I've gotten reports of the tick catchup consuming a lot of CPU time
>    from rapid delivery of interrupts (although I haven't reproduced this
>    yet).
> 
> 3) Windows appears to have a service that periodically syncs the guest
>    time with the hardware clock.  I've been told the resync period is an
>    hour.  For large clock skews, this can compete with reinjection
>    resulting in a positive skew in time (the guest can be ahead of the
>    host).
> 
> I've been thinking about an algorithm like this to address these
> problems:
> 
> A) Limit the number of interrupts that we reinject to the equivalent of
>    a small period of wallclock time.  Something like 60 seconds.
> 
> B) In the event of (A), trigger a notification in QEMU.  This is easy
>    for the RTC but harder for the in-kernel PIT.  Maybe it's a good time to
>    revisit usage of the in-kernel PIT?
> 
> C) On acculumated tick overflow, rely on using a qemu-ga command to
>    force a resync of the guest's time to the hardware wallclock time.
> 
> D) Whenever the guest reads the wallclock time from the RTC, reset all
>    accumulated ticks.
> 
> In order to do (C), we'll need to plumb qemu-ga through QMP.  Mike and I
> discussed a low-impact way of doing this (having a separate dispatch
> path for guest agent commands) and I'm confident we could do this for
> 1.3.

Fine with me, but note that we're only two or three commands away from
having the qapi conversion done. So, it's possible that we'll merge this
and re-do it a few weeks later.

> This would mean that management tools would need to consume qemu-ga
> through QMP.  Not sure if this is a problem for anyone.

Shouldn't be a problem I think.

> 
> I'm not sure whether it's worth trying to support this with the
> in-kernel PIT or not either.
> 
> Are there other issues with reinjection that people are aware of?  Does
> anything seem obviously wrong with the above?
> 
> Regards,
> 
> Anthony Liguori
>