Re: [Qemu-devel] Rethinking missed tick catchup

[Gleb Natapov <gleb@redhat.com>]

On Wed, Sep 19, 2012 at 07:44:27PM +0300, Avi Kivity wrote:
> On 09/19/2012 07:37 PM, Gleb Natapov wrote:
> > On Wed, Sep 19, 2012 at 06:34:46PM +0300, Avi Kivity wrote:
> >> On 09/16/2012 05:37 PM, Anthony Liguori wrote:
> >> > Avi Kivity <avi@redhat.com> writes:
> >> > 
> >> >> On 09/13/2012 09:27 PM, Anthony Liguori wrote:
> >> >>> If there was a better/equivalent solution that didn't depend on qemu-ga,
> >> >>> I'd be all for it.  But there isn't AFAICT.
> >> >>
> >> >> Perhaps there is.  We fixed the problem for Linux by adding kvmclock and
> >> >> backporting it to distros that users are most likely to use.  Windows
> >> >> fixed the problem by adding their own pv clock interface.  So we need to
> >> >> implement that, then focus on tick catchup for Windows XP and other
> >> >> guests with no pv interface (*BSD, etc.)
> >> > 
> >> > Tick catchup simply isn't going to work.  That's the whole point of the thread.
> >> 
> >> I'll restate.  Windows and Linux don't need either qemu-ga or tick
> >> catchup since they have pv time interfaces.  FreeBSD and less frequently
> >> used guests are unlikely to get a qemu-ga port, so they need tick
> >> catchup.  Is there reason to believe tick catchup won't work on FreeBSD?
> >> 
> > If FreeBSD tries to compensate for lost ticks it may not work.
> 
> Right, the problem is with guests that are too clever for their own
> good.  No idea where FreeBSD (or the others, just using it as a
> placeholder) fall.  But my guess is that the less popular the guest, the
> fewer dirty tricks it pulls.
> 
> > 
> >> >>
> >> >> Those older guests are also less likely to have a qemu-ga port or
> >> >> administrator motivation to install it.
> >> > 
> >> > That's a strange assertion to make.  FWIW, the issue with hibernation
> >> > was reported to me with a combination of WinXP and Windows 7 guests, in
> >> > this case, it's a totally new deployment.  Adding qemu-ga is totally
> >> > reasonable.
> >> 
> >> Windows 7 doesn't need anything if we implement the pv time interface.
> > What PV interface exactly? According to [1] Hyper-v also tries to
> > "catch-up" timer by shortening timer period unless to many events were
> > missed.
> > 
> > [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff542561%28v=vs.85%29.aspx
> > 
> 
> Reference Time Counter.  If Windows uses that in preference to the tick,
> then tick catch up is immaterial.
> 
Windows uses it for QPC if iTSC (kvmclock) is not available. I am not at
all sure Windows uses Reference Time Counter for time keeping.

> 
> >> That is less effort than requiring a qemu-ga installation.  Windows XP
> >> is an edge case.  We can of course support qemu-ga for it, or we can
> >> massage the tick code to work with it, since it's timekeeping is likely
> >> a lot less sophisticated than 7's.
> >> 
> > How do you propose to "massage the tick code" to compensate for 100
> > hours of missed ticks in a sane way? 
> 
> Probably not solvable.  But I'm less concerned about host suspend and
> more about overcommit, which is more likely to cause missed ticks in
> practice.
> 
> > As far as I know there is no
> > difference in timekeeping between Windows XP and Windows 7 (at least
> > without PV).
> 
> Including the rtc resync?
> 
You mean resync time with RTC from time to time. I think so. In practice
I didn't hear any complains about it for any Windows. We can solve
resync problem easily though by reporting time as "current time" - "time we
going to reinject"

--
			Gleb.