Re: [Qemu-devel] Rethinking missed tick catchup

[Avi Kivity]

On 09/19/2012 07:55 PM, Gleb Natapov wrote:
> 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 <address@hidden> 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.

Would be good to know, except...

> 
>> 
>> >> 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"

Clever!  I think this is a point in favour of tick catchup (also, the
fact the hyper-v uses it).  Of course it's hard to implement with some
time sources in the kernel and some in qemu.

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