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
