From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37776 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmSoy-0005W1-Jq for qemu-devel@nongnu.org; Mon, 07 Feb 2011 10:16:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmSow-0002oq-Ck for qemu-devel@nongnu.org; Mon, 07 Feb 2011 10:16:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmSow-0002oi-2Z for qemu-devel@nongnu.org; Mon, 07 Feb 2011 10:16:06 -0500 Message-ID: <4D500CB0.4000208@redhat.com> Date: Mon, 07 Feb 2011 17:16:00 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift 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> In-Reply-To: <4D500C39.3040801@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Glauber Costa , Ulrich Obergfell , kvm 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