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 <a...@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.
