From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer
 emulation to alleviate time drift
Date: Mon, 07 Feb 2011 08:28:48 -0600
Message-ID: <4D5001A0.8020503@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ulrich Obergfell <uobergfe@redhat.com>,
	Glauber Costa <glommer@redhat.com>,
	Avi Kivity <avi@redhat.com>, kvm <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-wy0-f174.google.com ([74.125.82.174]:60439 "EHLO
	mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752551Ab1BGO2x (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 7 Feb 2011 09:28:53 -0500
Received: by wyb28 with SMTP id 28so4593729wyb.19
        for <kvm@vger.kernel.org>; Mon, 07 Feb 2011 06:28:51 -0800 (PST)
In-Reply-To: <4D4FFD3B.2030903@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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);

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);

Regards,

Anthony Liguori

> Jan
>
>