From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49326 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmSJ8-0006Rx-Ew for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:43:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmSJ7-0004TE-9m for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:43:14 -0500 Received: from goliath.siemens.de ([192.35.17.28]:16933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmSJ6-0004Sz-So for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:43:13 -0500 Message-ID: <4D5004FC.80000@siemens.com> Date: Mon, 07 Feb 2011 15:43:08 +0100 From: Jan Kiszka 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> In-Reply-To: <4D5001A0.8020503@codemonkey.ws> 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: qemu-devel , Glauber Costa , Ulrich Obergfell , kvm , Avi Kivity On 2011-02-07 15:28, Anthony Liguori wrote: > On 02/07/2011 08:10 AM, Jan Kiszka wrote: >> Again: please not in an ad-hoc fashion but as a generic services usable >> by _all_ periodic timer sources that want to implement compensation. >> This infrastructure should also be designed to once integrate IRQ >> coalescing information as well. >> >> The point why I'm insisting on a broader solution is that both sources >> for lost ticks (iothread and vcpu) end up in the same output: an >> adjustment of the injection frequency of the affected timer device. >> There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the >> SoC timer of some emulated ARM board as well. >> > > Fair enough, how about: > > typedef struct PeriodicTimer PeriodicTimer; > > /** > * @accumulated_ticks: the number of unacknowledged ticks in total > since the creation of the timer > **/ > typedef void (PeriodicTimer)(void *opaque, int accumulated_ticks); I guess you mean PeriodicTimerFunc. Why the accumulated_ticks argument? > > PeriodicTimer *periodic_timer_new(PeriodicTimerFunc *cb, void *opaque); > > void periodic_timer_mod(PeriodicTimer *timer, int64_t interval, TimeUnit > unit); > > /** > * @policy: the drift catch-up policy > * DRIFT_COMP_FAST, deliver next tick as soon as any > tick is acknowledged if accumulated_ticks > 1 > * DRIFT_COMP_NONE, do not change interval regardless of > accumulated ticks > * DRIFT_COMP_GRADUAL, shorten interval by half until > accumulated_ticks <= 1 > */ > void periodic_timer_set_policy(PeriodicTimer *timer, > DriftCompensationPolicy policy); > > /** > * @ticks: number of ticks to acknowledge that are currently outstanding. > **/ > void periodic_timer_ack(PeriodicTimer *timer, int ticks); > Looks reasonable otherwise. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux