From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift Date: Mon, 07 Feb 2011 07:24:52 -0600 Message-ID: <4D4FF2A4.8020104@codemonkey.ws> 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> <4D4B0B07.2040904@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ulrich Obergfell , Glauber Costa , Avi Kivity , kvm , qemu-devel , Michael D Roth To: Jan Kiszka Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:54209 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752261Ab1BGNY6 (ORCPT ); Mon, 7 Feb 2011 08:24:58 -0500 Received: by wyb28 with SMTP id 28so4529786wyb.19 for ; Mon, 07 Feb 2011 05:24:56 -0800 (PST) In-Reply-To: <4D4B0B07.2040904@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Hi Ulrich, Mike Roth just posted a mechanism to implement per-device unit tests. I think this is a great example to use for what type of testing we should be doing in QEMU. Please take a look at Mike's series and see if you can do something similar for HPET as he's doing for the RTC. Regards, Anthony Liguori On 02/03/2011 02:07 PM, Anthony Liguori wrote: > 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 >> >