From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBpcB-0003gX-Cx for qemu-devel@nongnu.org; Wed, 12 Sep 2012 12:16:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBpc6-0001AH-T0 for qemu-devel@nongnu.org; Wed, 12 Sep 2012 12:16:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8671) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBpc6-0001A8-KI for qemu-devel@nongnu.org; Wed, 12 Sep 2012 12:16:30 -0400 Date: Wed, 12 Sep 2012 19:16:25 +0300 From: Gleb Natapov Message-ID: <20120912161625.GC25041@redhat.com> References: <87pq5r5otp.fsf@codemonkey.ws> <50509A66.7010505@siemens.com> <87y5kfi9mt.fsf@codemonkey.ws> <20120912150647.GS20907@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120912150647.GS20907@redhat.com> Subject: Re: [Qemu-devel] Rethinking missed tick catchup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "qemu-devel@nongnu.org" , Jan Kiszka , Michael Roth , Luiz Capitulino , Avi Kivity , Paolo Bonzini , Eric Blake On Wed, Sep 12, 2012 at 06:06:47PM +0300, Gleb Natapov wrote: > On Wed, Sep 12, 2012 at 09:44:10AM -0500, Anthony Liguori wrote: > > Jan Kiszka writes: > > > > > On 2012-09-12 15:54, Anthony Liguori wrote: > > >> > > >> 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. > > > > > > As with our current discussion around fixing the PIC and its impact on > > > the PIT, we should try on the userspace model first and then check if > > > the design can be adapted to support in-kernel as well. > > > > > > For which guests is the PIT important again? Old Linux kernels? Windows > > > should be mostly happy with the RTC - or the HPET. > > > > I thought that only 64-bit Win2k8+ used the RTC. > > > > I thought win2k3 and even 32-bit win2k8 still used the PIT. > > > Only WindowsXP non-acpi hal uses PIT. Any other windows uses RTC. In > other words we do not care about PIT. > Small clarification. They use RTC if HPET is not present. I don't know at what version Windows started to prefer HPET over RTC. -- Gleb.