On 09/19/2012 07:55 PM, Gleb Natapov wrote: > On Wed, Sep 19, 2012 at 07:44:27PM +0300, Avi Kivity wrote: >> 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 <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? >> >> >> > 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. >> > Windows uses it for QPC if iTSC (kvmclock) is not available. I am not at > all sure Windows uses Reference Time Counter for time keeping.
Would be good to know, except... > >> >> >> 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? >> > You mean resync time with RTC from time to time. I think so. In practice > I didn't hear any complains about it for any Windows. We can solve > resync problem easily though by reporting time as "current time" - "time we > going to reinject" Clever! I think this is a point in favour of tick catchup (also, the fact the hyper-v uses it). Of course it's hard to implement with some time sources in the kernel and some in qemu. -- error compiling committee.c: too many arguments to function
