From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvcSx-0006Ji-Ih for qemu-devel@nongnu.org; Mon, 22 Aug 2011 17:55:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvcSv-0004jm-Cl for qemu-devel@nongnu.org; Mon, 22 Aug 2011 17:55:31 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:40855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvcSv-0004jV-5a for qemu-devel@nongnu.org; Mon, 22 Aug 2011 17:55:29 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7MLqGSH002344 for ; Mon, 22 Aug 2011 15:52:16 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7MLtQoC169834 for ; Mon, 22 Aug 2011 15:55:27 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7MLtQmN027339 for ; Mon, 22 Aug 2011 15:55:26 -0600 Message-ID: <4E52D04D.7040606@us.ibm.com> Date: Mon, 22 Aug 2011 16:55:25 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1314040874-9259-1-git-send-email-aliguori@us.ibm.com> <1314040874-9259-2-git-send-email-aliguori@us.ibm.com> <4E52BBF2.3040102@web.de> <4E52BDB4.5060704@codemonkey.ws> <4E52C0E1.3080503@web.de> In-Reply-To: <4E52C0E1.3080503@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] [RFC] time: refactor QEMU timer to use GHRTimer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , qemu-devel@nongnu.org On 08/22/2011 03:49 PM, Jan Kiszka wrote: > On 2011-08-22 22:36, Anthony Liguori wrote: >> On 08/22/2011 03:28 PM, Jan Kiszka wrote: >>> On 2011-08-22 21:21, Anthony Liguori wrote: >>>> This replaces all of the QEMU timer code with GHRTimer, dramatically >>>> simplifying >>>> time keeping in QEMU while making it possible to use QEMUTimer code >>>> outside of >>>> the main loop. The later is critical to building unit tests. >>>> >>>> This is an RFC because I'm sure this breaks things as it changes >>>> things. QEMU >>>> time keeping is quite a mess today. Here's what we do today: >>>> >>>> 1) We have three clocks: >>>> a) the real time clock, based on system time, not monotonic >>>> b) the host clock, based on the real time clock, monotonic by >>>> detecting >>>> movements backward in time >>>> c) the vm clock, based on real time clock but may start/stop with >>>> the guest >>> >>> Not quite correct. We have: >>> >>> - QEMU_CLOCK_REALTIME: Based on monotonic source *if* the host >>> supports it (there were probably once some stone-old Linuxes or >>> BSDs), otherwise based on gettimeofday, i.e. non-monotonic. Always >>> monotonic on Windows. >> >> The only clock on Linux that is truly monotonic is CLOCK_MONOTONIC_RAW >> which is very new (2.6.28+). CLOCK_MONOTONIC is not actually monotonic >> as it's subject to adjustments. > > CLOCK_MONOTONIC may be subject to frequency tuning while > CLOCK_MONOTONIC_RAW is not. That does not and must not (for POSIX > compliance) make the former non-monotonic. Yes, you are right. I got myself confused. >>> These two assessments are partly just wrong, partly fail to see the real >>> use case. QEMU_CLOCK_HOST serves the very valid scenarios where a guest >>> clock shall be kept synchronized on the host time, also following its >>> jumps accordingly without stalling timers. >> >> The only reason we see jumps at all is because we're using >> CLOCK_MONOTONIC or CLOCK_REALTIME. If we used CLOCK_MONOTONIC_RAW, we >> don't see any jumps at all. > > CLOCK_MONOTONIC will not jump backward as well, so is perfectly fine and > better portable. Backward jumps cannot be avoided when using a host > system clock that is subject to follow a more accurate external source. > But having such source for RTC emulation e.g. is a useful feature. I think its of limited utility. The RTC isn't universally used for time keeping. There's also no guarantee that the guest isn't going to be upset by this. I think a better approach is to simply have a verb in qemu-ga to set/get the guest time. That let's you implement clock adjustment without having to worry about NTP. I'm happy to add that as part of this series. I don't think messing around with this stuff belongs in the QEMU clock layer though. Regards, Anthony Liguori > Jan