From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift Date: Mon, 07 Feb 2011 17:16:00 +0200 Message-ID: <4D500CB0.4000208@redhat.com> 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> <4D4BBF55.9060000@web.de> <4D4FE6BF.5080502@redhat.com> <4D4FEF81.1040603@codemonkey.ws> <4D4FF02F.2030309@redhat.com> <4D4FF24A.7000004@codemonkey.ws> <4D4FFD3B.2030903@siemens.com> <4D5001A0.8020503@codemonkey.ws> <4D5004FC.80000@siemens.com> <4D5007B9.7060806@codemonkey.ws> <4D5008B3.90505@redhat.com> <4D50094D.1040003@siemens.com> <4D500AFC.4040206@redhat.com> <4D500C39.3040801@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Ulrich Obergfell , Glauber Costa , kvm , qemu-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53037 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753591Ab1BGPQH (ORCPT ); Mon, 7 Feb 2011 10:16:07 -0500 In-Reply-To: <4D500C39.3040801@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/07/2011 05:14 PM, Jan Kiszka wrote: > On 2011-02-07 16:08, Avi Kivity wrote: > > On 02/07/2011 05:01 PM, Jan Kiszka wrote: > >>> > >>> On the other hand, we need a way to inject lost ticks into a > >>> PeriodicTimer. If interrupt injection detects that an interrupt was > >>> coalesced, we want the timer to schedule a new tick for us. > >> > >> Isn't absence of corresponding call to periodic_timer_ack() sufficient? > > > > It probably is. However, that API is easy to misuse; if you forget to > > call it, the timer goes crazy. The default behaviour should be to > > assume an ack and the API should provide adjustments. > > Explicit nack'ing only works smoothly if we have immediate (synchronous) > feedback about the injected event. My feeling is that ack'ing results in > simpler, thus also easier to review code. Yes. Maybe we should have an auto-ack mode, so that code that doesn't have ack notification doesn't need to bother with it. > > > > Also need to design the API carefully for changing frequency (Windows is > > known to do that) and switching from periodic to single shot. For the > > first case I guess we need to adjust the deferred ticks to the new time > > base (so if the frequency doubles, the lost ticks up to that point > > double as well). For the second case, I guess we just lose time. > > I think this is rather a question how the logic behind > periodic_timer_mod works with updates. The API should be sufficient as > simple as it is. Yes, it's an implementation detail. -- error compiling committee.c: too many arguments to function