Re: [Qemu-devel] Rethinking missed tick catchup

[Avi Kivity <avi@redhat.com>]

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.


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

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