From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBnOm-0003iI-I9 for qemu-devel@nongnu.org; Wed, 12 Sep 2012 09:54:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBnOi-0006UF-DW for qemu-devel@nongnu.org; Wed, 12 Sep 2012 09:54:36 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:49235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBnOi-0006U3-7Z for qemu-devel@nongnu.org; Wed, 12 Sep 2012 09:54:32 -0400 Received: by obbta14 with SMTP id ta14so2441378obb.4 for ; Wed, 12 Sep 2012 06:54:30 -0700 (PDT) From: Anthony Liguori Date: Wed, 12 Sep 2012 08:54:26 -0500 Message-ID: <87pq5r5otp.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Rethinking missed tick catchup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Gleb Natapov , Jan Kiszka , Michael Roth , Luiz Capitulino , Avi Kivity , Paolo Bonzini , Eric Blake Hi, We've been running into a lot of problems lately with Windows guests and I think they all ultimately could be addressed by revisiting the missed tick catchup algorithms that we use. Mike and I spent a while talking about it yesterday and I wanted to take the discussion to the list to get some additional input. Here are the problems we're seeing: 1) Rapid reinjection can lead to time moving faster for short bursts of time. We've seen a number of RTC watchdog BSoDs and it's possible that at least one cause is reinjection speed. 2) When hibernating a host system, the guest gets is essentially paused for a long period of time. This results in a very large tick catchup while also resulting in a large skew in guest time. I've gotten reports of the tick catchup consuming a lot of CPU time from rapid delivery of interrupts (although I haven't reproduced this yet). 3) Windows appears to have a service that periodically syncs the guest time with the hardware clock. I've been told the resync period is an hour. For large clock skews, this can compete with reinjection resulting in a positive skew in time (the guest can be ahead of the host). I've been thinking about an algorithm like this to address these problems: A) Limit the number of interrupts that we reinject to the equivalent of a small period of wallclock time. Something like 60 seconds. B) In the event of (A), trigger a notification in QEMU. This is easy for the RTC but harder for the in-kernel PIT. Maybe it's a good time to revisit usage of the in-kernel PIT? C) On acculumated tick overflow, rely on using a qemu-ga command to force a resync of the guest's time to the hardware wallclock time. D) Whenever the guest reads the wallclock time from the RTC, reset all accumulated ticks. In order to do (C), we'll need to plumb qemu-ga through QMP. Mike and I discussed a low-impact way of doing this (having a separate dispatch path for guest agent commands) and I'm confident we could do this for 1.3. This would mean that management tools would need to consume qemu-ga through QMP. Not sure if this is a problem for anyone. I'm not sure whether it's worth trying to support this with the in-kernel PIT or not either. Are there other issues with reinjection that people are aware of? Does anything seem obviously wrong with the above? Regards, Anthony Liguori