From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35726 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl5Su-00006X-Tw for qemu-devel@nongnu.org; Thu, 03 Feb 2011 15:07:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pl5St-0000ou-LQ for qemu-devel@nongnu.org; Thu, 03 Feb 2011 15:07:40 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:37855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pl5St-0000oW-J9 for qemu-devel@nongnu.org; Thu, 03 Feb 2011 15:07:39 -0500 Received: by vws12 with SMTP id 12so935081vws.4 for ; Thu, 03 Feb 2011 12:07:39 -0800 (PST) Message-ID: <4D4B0B07.2040904@codemonkey.ws> Date: Thu, 03 Feb 2011 14:07:35 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift References: <480481933.225059.1296734409954.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <1375835067.226263.1296740625327.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4D4AC99A.2070803@siemens.com> In-Reply-To: <4D4AC99A.2070803@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Glauber Costa , Ulrich Obergfell , kvm , Avi Kivity On 02/03/2011 09:28 AM, Jan Kiszka wrote: > On 2011-02-03 14:43, Ulrich Obergfell wrote: > >> Hi, >> >> I am observing severe backward time drift in a MS Windows Vista(tm) >> guest running on a Fedora 14 KVM host. I can reproduce the problem >> with the following steps: >> >> 1. Use 'vncviewer' to connect to the guest's desktop. >> 2. Click on the menu title bar of a window on the guest's desktop. >> 3. Move that window around on the guest's desktop. >> >> While I keep on moving the window around for one minute, the guest >> time falls up to 15 seconds behind host time. >> >> The problem is caused by delayed callbacks of hpet_timer(). A timer >> interrupt is injected into the guest during each callback. However, >> interrupts are lost if delays are greater than a comparator period. >> >> > Yes, that's a well known limitation of qemu, in fact. We are lacking a > generic irq coalescing infrastructure. That, once designed and > available, would also allow to fix the HPET. > I don't think it requires anything that sophisticated. It's just the period calculation of the HPET that's wrong and doesn't account for loss. > >> This is an RFC through which I would like to get feedback on how the >> idea of a patch to compensate those lost interrupts would be received: >> >> The patch determines the number of lost timer interrupts based on the >> number of elapsed comparator periods. Lost interrupts are compensated >> > That neglects coalescing of the HPET IRQs: If the timer is run regularly > but the guest is not able to retrieve the injected IRQs, you should > still see drifts with your patches. > FWIW, this isn't the most common failure scenario. This is only really prominent when you have rapid reinject like we do with the in-kernel PIT. This generally shouldn't be an issue with gradual reinjection. >> by gradually injecting additional interrupts during the subsequent >> timer intervals, starting at a rate of one additional interrupt per >> interval. If further interrupts are lost while compensation is still >> in progress, the rate is increased. The algorithm imposes a limit on >> the rate and on the 'backlog' of lost interrupts to be injected. The >> patch can be enabled via a qemu command line option. >> >> -hpet [device=none|present][,driftfix=none|slew] >> >> The 'device=none' option is equivalent to the '-no-hpet' option, and >> the 'driftfix=slew' option enables the patch (similar to RTC). >> >> >> The second and third part of this series of email contain the patch: >> >> - Code part 1 introduces the qemu command line option. >> - Code part 2 implements compensation of lost interrupts. >> >> Please review and please comment. >> >> > Generally, this issue needs to be attacked at qemu level (added to CC), > not qemu-kvm. > > We had a lengthy discussion on the list last year. We (including qemu > people) basically agreed that we needs a generic feedback infrastructure > to track coalesced IRQs for periodic, clock providing devices to allow > reinjection (which would include reinjection of completely missed timer > events like in your series). > This really isn't the main problem. Regards, Anthony Liguori > However, there was one unsolved design issue remain IIRC: > > http://thread.gmane.org/gmane.comp.emulators.qemu/73181 > > Once we have a proper answer for this, we can resume creating the > de-coalescing framework. > > Jan > >