From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvzUz-0001T2-6e for qemu-devel@nongnu.org; Fri, 31 Oct 2008 15:17:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvzUw-0001Rv-3d for qemu-devel@nongnu.org; Fri, 31 Oct 2008 15:17:32 -0400 Received: from [199.232.76.173] (port=58371 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvzUv-0001Rs-V0 for qemu-devel@nongnu.org; Fri, 31 Oct 2008 15:17:29 -0400 Received: from yx-out-1718.google.com ([74.125.44.156]:24352) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvzUv-0004BF-M8 for qemu-devel@nongnu.org; Fri, 31 Oct 2008 15:17:30 -0400 Received: by yx-out-1718.google.com with SMTP id 3so572505yxi.82 for ; Fri, 31 Oct 2008 12:17:23 -0700 (PDT) Message-ID: <490B59BF.3000205@codemonkey.ws> Date: Fri, 31 Oct 2008 14:17:19 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. References: <20081029152236.14831.15193.stgit@dhcp-1-237.local> In-Reply-To: <20081029152236.14831.15193.stgit@dhcp-1-237.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Gleb Natapov wrote: > Qemu device emulation for timers might be inaccurate and > causes coalescing of several IRQs into one. It happens when the > load on the host is high and the guest did not manage to ack the > previous IRQ. The problem can be reproduced by copying of a big > file or many small ones inside Windows guest. When you do that > guest clock start to lag behind the host one. > > The first patch in the series changes qemu_irq subsystem to return > IRQ delivery status information. If device is notified that IRQs > where lost it can regenerate them as needed. The following two > patches add IRQ regeneration to PIC and RTC devices. > I don't think any of the problems raised when this was initially posted. Further, I don't think that always playing catch-up with interrupts is always the best course of action. As I've said repeatedly in the past, any sort of time drift fixes needs to have a lot of data posted with it that is repeatable. How much does this improve things with Windows? How does having a high resolution timer in the host affect the problem to begin with? How do Linux guests behave with this? Even the Windows PV spec calls out three separate approaches to dealing with missed interrupts and provides an interface for the host to query the guest as to which one should be used. I don't think any solution that uses a single technique is going to be correct. Regards, Anthony Liguori