From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift Date: Mon, 07 Feb 2011 15:57:54 +0100 Message-ID: <4D500872.3070506@siemens.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ulrich Obergfell , Glauber Costa , Avi Kivity , kvm , qemu-devel To: Anthony Liguori Return-path: Received: from goliath.siemens.de ([192.35.17.28]:17838 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753172Ab1BGO6K (ORCPT ); Mon, 7 Feb 2011 09:58:10 -0500 In-Reply-To: <4D5007B9.7060806@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 2011-02-07 15:54, Anthony Liguori wrote: > On 02/07/2011 08:43 AM, Jan Kiszka wrote: >> 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. > > Yes. > >> Why the accumulated_ticks argument? >> > > Then the missing ticks is stored in the PeriodicTimer instead of storing > it in the device state. That means we won't forget to save it in vmstate. There should rather be a special vmstate struct for PeriodicTimer, just like we already have for normal timers. > > 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). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43962 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmSXO-0004yu-Ka for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:57:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmSXN-0007Zn-Hk for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:57:58 -0500 Received: from goliath.siemens.de ([192.35.17.28]:15741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmSXN-0007Zb-8D for qemu-devel@nongnu.org; Mon, 07 Feb 2011 09:57:57 -0500 Message-ID: <4D500872.3070506@siemens.com> Date: Mon, 07 Feb 2011 15:57:54 +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> <4D5004FC.80000@siemens.com> <4D5007B9.7060806@codemonkey.ws> In-Reply-To: <4D5007B9.7060806@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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:54, Anthony Liguori wrote: > On 02/07/2011 08:43 AM, Jan Kiszka wrote: >> 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. > > Yes. > >> Why the accumulated_ticks argument? >> > > Then the missing ticks is stored in the PeriodicTimer instead of storing > it in the device state. That means we won't forget to save it in vmstate. There should rather be a special vmstate struct for PeriodicTimer, just like we already have for normal timers. > > 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). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux