From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift Date: Fri, 04 Feb 2011 09:56:53 +0100 Message-ID: <4D4BBF55.9060000@web.de> 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> <4D4B5F23.7040801@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig636EE56281D1F649521C469C" Cc: qemu-devel , Glauber Costa , Ulrich Obergfell , kvm , Avi Kivity To: Anthony Liguori Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:54369 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751703Ab1BDI5A (ORCPT ); Fri, 4 Feb 2011 03:57:00 -0500 In-Reply-To: <4D4B5F23.7040801@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig636EE56281D1F649521C469C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-02-04 03:06, Anthony Liguori wrote: > On 02/03/2011 03:24 PM, Jan Kiszka wrote: >> On 2011-02-03 21:07, Anthony Liguori wrote: >> =20 >>> On 02/03/2011 09:28 AM, Jan Kiszka wrote: >>> =20 >>>> On 2011-02-03 14:43, Ulrich Obergfell wrote: >>>> >>>> =20 >>>>> 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.= >>>>> >>>>> >>>>> =20 >>>> 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. >>>> >>>> =20 >>> 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. >>> =20 >> Blind (/wrt the guest state) reinjection from the iothread will >> compensate for lost time of *that* thread but not of the target vcpu(s= ). >> =20 >=20 > 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? >=20 > 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. But that's the only thing this patch is after: lost ticks at QEMU level. >=20 >> So, depending on your workload, you may reduce the drift more or less,= >> but you won't fix it this way. >> =20 >=20 > There is no such thing as "fix" it. Time drift can happen on bare meta= l > too. Interrupts can be coalesced due to crappy SMM code. It's > something we see quite a lot in practice. We don't have this issues. Relative to the host's time base, we can actually prevent lost ticks, thus drift. >=20 > 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. >=20 > 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. I don't disagree. The question is just how to detect guest-missed ticks. >=20 > 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 gradua= l > policy, it shouldn't be a huge issue. Again, I don't disagree, but I would like to finally attack this in a non-ad-hoc manner, specifically when going upstream. The input & output infrastructure (aka injection feedback), and all these calculations should be generically available so that we do not reinvent the wheel every time we add another timer device that guests me use for time keeping. This issue is surely not an x86-only thing. Even on x86, we need it also for the PIT and the RTC, conceptually also for the APIC when configured in periodic mode. Jan --------------enig636EE56281D1F649521C469C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Lv1kACgkQitSsb3rl5xSetwCeIHlQ4s274ofmV8d0avbEIOj4 hqwAn1P6wflHe97Ap0dMwAcnJmEhyMw2 =tLsV -----END PGP SIGNATURE----- --------------enig636EE56281D1F649521C469C--