From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TENas-0003CW-6f for qemu-devel@nongnu.org; Wed, 19 Sep 2012 12:57:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TENal-0006g0-Mp for qemu-devel@nongnu.org; Wed, 19 Sep 2012 12:57:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28318) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TENal-0006fO-EH for qemu-devel@nongnu.org; Wed, 19 Sep 2012 12:57:39 -0400 Message-ID: <5059F97C.1030405@redhat.com> Date: Wed, 19 Sep 2012 19:57:32 +0300 From: Avi Kivity MIME-Version: 1.0 References: <5051F0CB.9040303@redhat.com> <5051FE85.6070904@redhat.com> <87har1orbl.fsf@codemonkey.ws> <50520189.3050707@redhat.com> <87627h7p7n.fsf@codemonkey.ws> <5055A459.1030909@redhat.com> <87vcfenieq.fsf@codemonkey.ws> <5059E616.5080500@redhat.com> <20120919163745.GB26958@redhat.com> <5059F66B.3010704@redhat.com> <20120919165501.GC26958@redhat.com> In-Reply-To: <20120919165501.GC26958@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Rethinking missed tick catchup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Jan Kiszka , Michael Roth , qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini , Luiz Capitulino , Eric Blake 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 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