From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift Date: Mon, 07 Feb 2011 09:01:00 -0600 Message-ID: <4D50092C.1080109@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , qemu-devel , Glauber Costa , Ulrich Obergfell , kvm , Avi Kivity To: Jan Kiszka Return-path: Received: from mail-bw0-f46.google.com ([209.85.214.46]:35671 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752828Ab1BGPD5 (ORCPT ); Mon, 7 Feb 2011 10:03:57 -0500 Received: by bwz15 with SMTP id 15so4980776bwz.19 for ; Mon, 07 Feb 2011 07:03:55 -0800 (PST) In-Reply-To: <4D500872.3070506@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 > >