From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33699 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmSdC-00082F-8M for qemu-devel@nongnu.org; Mon, 07 Feb 2011 10:03:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmSdB-0000gR-3M for qemu-devel@nongnu.org; Mon, 07 Feb 2011 10:03:58 -0500 Received: from mail-ew0-f45.google.com ([209.85.215.45]:37399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmSdA-0000gM-Oj for qemu-devel@nongnu.org; Mon, 07 Feb 2011 10:03:56 -0500 Received: by ewy10 with SMTP id 10so2364906ewy.4 for ; Mon, 07 Feb 2011 07:03:55 -0800 (PST) Message-ID: <4D50092C.1080109@codemonkey.ws> Date: Mon, 07 Feb 2011 09:01:00 -0600 From: Anthony Liguori 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> <4D500872.3070506@siemens.com> In-Reply-To: <4D500872.3070506@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: kvm , Glauber Costa , qemu-devel , Ulrich Obergfell , Avi Kivity On 02/07/2011 08:57 AM, Jan Kiszka wrote: > There should rather be a special vmstate struct for PeriodicTimer, just > like we already have for normal timers. > Agreed. >> It's convenient because then if we lose ticks in the PeriodicTimer >> layer, the devices have instance access to that info. When you do a >> read() from timerfd, it returns the number of coalesced events. That's >> the interface I had in my mind. >> >> We could just add a getter for PeriodicTimer and it would serve the same >> purpose. >> > I'm still not sure what the device model is supposed to do with that > information. I think at could remain private to the PeriodicTimer > implementation (unless we want to dump some stats or such). > Yeah, I've been thinking about it too and I think I agree with you. So here's the new proposal: typedef struct PeriodicTimer PeriodicTimer; /** * @accumulated_ticks: the number of unacknowledged ticks in total since the creation of the timer **/ typedef void (PeriodicTimerFunc)(void *opaque); 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); int periodic_timer_get_accumulated_ticks(PeriodicTimer *timer); Regards, Anthony Liguori > Jan > >