On 09/16/2012 05:37 PM, Anthony Liguori wrote: > Avi Kivity <a...@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
