Re: [Qemu-devel] Rethinking missed tick catchup

[Avi Kivity <avi@redhat.com>]

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?

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

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