Re: [Qemu-devel] Rethinking missed tick catchup

[Avi Kivity <avi@redhat.com>]

On 09/13/2012 09:27 PM, Anthony Liguori wrote:
>>> 
>>> Plus, there's a whole variety of other features enabled once we can
>>> assume qemu-ga is available.  It's worth solving that problem.
>>
>> We can't assume it.  Too many OSes exist, too many guests are already
>> exist and ain't broken, too many vendors are moving into a locked-down
>> model.  I agree it's great and we should take advantage of it, but we
>> can't assume it's there.
> 
> All the same can be said about virtio yet we still add features that
> depend on it.

We don't.  We can boot out-of-the-box guests and they will be fully
functioning without virtio, if slow.

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

Those older guests are also less likely to have a qemu-ga port or
administrator motivation to install it.


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