From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCYhA-0001ZU-N6 for qemu-devel@nongnu.org; Tue, 27 Mar 2012 11:52:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCYh0-0006P4-Pk for qemu-devel@nongnu.org; Tue, 27 Mar 2012 11:52:28 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:48605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCYh0-0006Oj-DB for qemu-devel@nongnu.org; Tue, 27 Mar 2012 11:52:18 -0400 Received: by pbcuo5 with SMTP id uo5so467056pbc.4 for ; Tue, 27 Mar 2012 08:52:16 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4F71E225.2010400@redhat.com> Date: Tue, 27 Mar 2012 17:52:05 +0200 From: Paolo Bonzini 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> In-Reply-To: <4F71D7D9.1040501@siemens.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: Jan Kiszka Cc: Lee Essen , Blue Swirl , =?ISO-8859-15?Q?Andreas_F=E4rber?= , "qemu-devel@nongnu.org" 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. Paolo