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: Thu, 03 Feb 2011 14:07:35 -0600 Message-ID: <4D4B0B07.2040904@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> 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 To: Jan Kiszka Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:59382 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756342Ab1BCUHj (ORCPT ); Thu, 3 Feb 2011 15:07:39 -0500 Received: by vws16 with SMTP id 16so932438vws.19 for ; Thu, 03 Feb 2011 12:07:39 -0800 (PST) In-Reply-To: <4D4AC99A.2070803@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 > >