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 20:06:27 -0600 Message-ID: <4D4B5F23.7040801@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> <4D4B1CF8.8040800@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , qemu-devel , Glauber Costa , Ulrich Obergfell , kvm , Avi Kivity To: Jan Kiszka Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:61974 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753721Ab1BDCGc (ORCPT ); Thu, 3 Feb 2011 21:06:32 -0500 Received: by vws16 with SMTP id 16so1159182vws.19 for ; Thu, 03 Feb 2011 18:06:31 -0800 (PST) In-Reply-To: <4D4B1CF8.8040800@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 02/03/2011 03:24 PM, Jan Kiszka wrote: > On 2011-02-03 21:07, 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. >> > Blind (/wrt the guest state) reinjection from the iothread will > compensate for lost time of *that* thread but not of the target vcpu(s). > Is the case your concern about where you try to set an interrupt from the I/O thread and the VCPU is not scheduled such that it doesn't actually get injected into KVM until after the period is over? This should be a rare event. If you are missing 50% of your notifications, not amount of gradual catchup is going to help you out. > So, depending on your workload, you may reduce the drift more or less, > but you won't fix it this way. > There is no such thing as "fix" it. Time drift can happen on bare metal too. Interrupts can be coalesced due to crappy SMM code. It's something we see quite a lot in practice. My point is that there's really low hanging fruit and while for some curious reason I don't actually see this patch, I believe that a patch like this probably can help us quite a lot in the short term. The think the two biggest problems we have right now are bad period calculations due to sloppy unit conversion (PIT/RTC) and lack of accounting for missed periods. It's worth noting again that if you don't use a gradual catchup policy, interrupt notifiers are extremely important because you're not going to inject before the end of the interrupt window. However, with a gradual policy, it shouldn't be a huge issue. Regards, Anthony Liguori > Jan > >