From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59084 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmOZw-0004C9-CH for qemu-devel@nongnu.org; Mon, 07 Feb 2011 05:44:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmOZv-0007Rv-08 for qemu-devel@nongnu.org; Mon, 07 Feb 2011 05:44:19 -0500 Received: from mx3-phx2.redhat.com ([209.132.183.24]:39602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmOZu-0007RG-OM for qemu-devel@nongnu.org; Mon, 07 Feb 2011 05:44:18 -0500 Date: Mon, 7 Feb 2011 05:44:14 -0500 (EST) From: Ulrich Obergfell Message-ID: <737716315.255957.1297075454268.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> In-Reply-To: <4D4B0B07.2040904@codemonkey.ws> Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , Glauber Costa , Avi Kivity , kvm , qemu-devel On 02/03/2011 9:07 PM, Anthony Liguori wrote: > On 02/03/2011 09:28 AM, Jan Kiszka wrote: >> On 2011-02-03 14:43, Ulrich Obergfell wrote: ... >>> 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. Anthony, Jan, many thanks for your feedback. I'm sorry for not responding earlier. I used the following KVM kernel module trace point in __apic_accept_irq() to trace coalesced interrupts related to HPET timer 0: result = !apic_test_and_set_irr(vector, apic); trace_kvm_apic_accept_irq(vcpu->vcpu_id, delivery_mode, trig_mode, vector, !result); While running the test outlined in my original email, I observed between 5 and 15 of these events occurring during one minute: qemu-system-x86-7632 [000] 3755.888909: kvm_apic_accept_irq: apicid 0 vec 209 (Fixed|edge) (coalesced) kvm->arch->vioapic.redirtbl[2] indicated that IRQ 2 was routed to vector number 209. With a comparator period of 15.6 milliseconds, the coalesced interrupts apparently contribute less than 250 milliseconds of drift. However, the total drift that I observed during one minute was up to 15 seconds. I think the patch could possibly handle coalesced interrupts too: - In update_irq(), use a similar method as in RTC emulation to detect coalesced interrupts. Return a delivery status to hpet_timer(). - In hpet_timer(), decrement t->irqs_to_inject (number of interrupts remaining to inject) only if the interrupt was not coalesced. Regards, Uli Obergfell