From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40740) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvbRF-00078f-Qw for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:49:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvbRC-0007os-Q1 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:49:41 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:57485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvbRC-0007of-EY for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:49:38 -0400 Message-ID: <4E52C0E1.3080503@web.de> Date: Mon, 22 Aug 2011 22:49:37 +0200 From: Jan Kiszka 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> In-Reply-To: <4E52BDB4.5060704@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1BFF06B195CAF961409675D2" Sender: jan.kiszka@web.de 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: Anthony Liguori Cc: Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1BFF06B195CAF961409675D2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 >> - QEMU_CLOCK_VIRTUAL: Without -icount, same as above, but stops when= >> the guest is stopped. The offset to compensate for stopped >> times is based on TSC, not sure why. With -icount, things get more= >> complicated, Paolo had some nice explanations for the details. >> >> - QEMU_CLOCK_HOST: That's the one always based on the host's system >> time (CLOCK_REALTIME) >> + it takes potentially configured offsets into acount >> + users of that clock can register callbacks on time warps into th= e >> past (to adjust pending timers) >=20 > Right, my assertion is that time warps are a bug as far as QEMU is > concerned. Is there any reason why the guest should care at all about > time warping in the host? Yes, to synchronize on an accurate host clock source without the need to add NTP-like services (or kvmclock) to the guest. So the warps are conceptionally valid, though still not very welcome. >=20 >>> 2) A "cpu ticks" clock that uses platform specific mechanisms (inline= >>> asm) >>> >>> 3) Various clock source implementations that may use a periodic timer= >>> or a >>> a dynamic time source. We have different implementations for >>> different >>> platforms >>> >>> 4) Time events are delivered via SIGALRM which means we end up >>> getting EINTRs >>> very often in QEMU. This is fairly annoying. Signals also race >>> against >>> select leading to a very ugly set of work arounds involving >>> writing data to >>> pipes. This is the sort of stuff in Unix programming that I wish= >>> I never had >>> to learn about and am very eager to eliminate in QEMU :-) >>> >>> (2) is just plain broken. In modern operating systems, >>> gettimeofday() is >>> optimized CPU instructions when they can be used safely. Often they >>> can't be >>> used safely and we ignore that in QEMU. For instance, on x86, RDTSC >>> races with >>> the scheduler (not to mention that the TSC is infamously unstable >>> across cores). >>> The kernel does the right thing here and provides the fastest method >>> that's >>> correct. >> >> I basically agree. Likely, these optimizations date back to the days >> Linux had no fast gettimeofday syscalls. Not sure what the state on >> other UNIXes is, but it's likely not worth keeping these optimizations= =2E >> Let's drop that one first and separately. >> >>> >>> (1.a) seems like a bug more than a feature. I don't see a lot of >>> disadvantages >>> to using a monotonic time source. >>> >>> (1.b) is a bit naive in its current form. Modern kernels export a tr= uly >>> monotonic time source which has a reliable frequency. Even though >>> (1.b) detects >>> backwards jumps, it doesn't do anything about large forward jumps >>> which can also >>> be problematic. >> >> These two assessments are partly just wrong, partly fail to see the re= al >> use case. QEMU_CLOCK_HOST serves the very valid scenarios where a gues= t >> clock shall be kept synchronized on the host time, also following its >> jumps accordingly without stalling timers. >=20 > 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. Jan --------------enig1BFF06B195CAF961409675D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5SwOEACgkQitSsb3rl5xTNlACgjb2pblQ5+8h76+kiggCkD6Ts FPgAoKa9x4lBYn/H0bwTcnjcCnVfyyNv =aVHV -----END PGP SIGNATURE----- --------------enig1BFF06B195CAF961409675D2--