From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCYph-0007IA-F9 for qemu-devel@nongnu.org; Tue, 27 Mar 2012 12:01:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCYpZ-0008VI-LH for qemu-devel@nongnu.org; Tue, 27 Mar 2012 12:01:17 -0400 Received: from goliath.siemens.de ([192.35.17.28]:22823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCYpZ-0008Uj-B0 for qemu-devel@nongnu.org; Tue, 27 Mar 2012 12:01:09 -0400 Message-ID: <4F71E436.7020603@siemens.com> Date: Tue, 27 Mar 2012 18:00:54 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1332606390-3605-1-git-send-email-lee.essen@nowonline.co.uk> <1332606390-3605-3-git-send-email-lee.essen@nowonline.co.uk> <4F71D631.5000007@redhat.com> <4F71D7D9.1040501@siemens.com> <4F71E225.2010400@redhat.com> In-Reply-To: <4F71E225.2010400@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/4] Enable qemu-timer dynticks for Solaris List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Lee Essen , Blue Swirl , =?ISO-8859-15?Q?Andreas_F=E4rber?= , "qemu-devel@nongnu.org" On 2012-03-27 17:52, Paolo Bonzini wrote: > Il 27/03/2012 17:08, Jan Kiszka ha scritto: >>>> +#if defined(__sun__) >>>> + if (timer_create(CLOCK_HIGHRES, &ev, &host_timer)) { >>>> +#else >>>> if (timer_create(CLOCK_REALTIME, &ev, &host_timer)) { >>>> +#endif >>> >>> This should be #ifdef CLOCK_HIGHRES. >> >> Are we sure about this is and will remain equivalent and correct? >> >> Also, I found some man page that says CLOCK_HIGHRES is non-adjustable >> while CLOCK_REALTIME is. That should make a difference in QEMU. > > Right, that's why I CCed you but then I forgot to ask the question. > > Does QEMU rely on CLOCK_REALTIME when "-rtc clock=host" is in use? A > monotonic clock would work better when CLOCK_REALTIME jumps backwards > (DST->solar). If the jump goes unnoticed, the alarm timer would have no > timeout for an hour or so. > > Of course the opposite is true when going from solar time to DST; you > move the realtime clock one hour forward and, with CLOCK_MONOTONIC, a > host_clock timer to trigger an hour too late. But the latter would be fixed up when we actually check for expired timers against the proper clocks. Hmm, I'm not sure anymore if we really need CLOCK_REALTIME for the timer here. This also has no telling history. Maybe the contributor of dynticks just didn't think about this aspect of REALTIME vs. MONOTONIC. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux