From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QveEe-0005bt-Df for qemu-devel@nongnu.org; Mon, 22 Aug 2011 19:48:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QveEd-0002il-59 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 19:48:52 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:49757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QveEc-0002iQ-PW for qemu-devel@nongnu.org; Mon, 22 Aug 2011 19:48:51 -0400 Message-ID: <4E52EADF.6000507@web.de> Date: Tue, 23 Aug 2011 01:48:47 +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> <4E52C0E1.3080503@web.de> <4E52D04D.7040606@us.ibm.com> In-Reply-To: <4E52D04D.7040606@us.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE6802152ADE18FB42194A047" 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 , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6802152ADE18FB42194A047 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-08-22 23:55, Anthony Liguori wrote: >>>> 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 gu= est >>>> clock shall be kept synchronized on the host time, also following it= s >>>> 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, w= e >>> don't see any jumps at all. >> >> CLOCK_MONOTONIC will not jump backward as well, so is perfectly fine a= nd >> better portable. Backward jumps cannot be avoided when using a host >> system clock that is subject to follow a more accurate external source= =2E >> But having such source for RTC emulation e.g. is a useful feature. >=20 > I think its of limited utility. The RTC isn't universally used for tim= e > keeping. There's also no guarantee that the guest isn't going to be > upset by this. That's why it's configurable. On the other hand, most guests are well-prepared to deal with the RTC and the host runtime clock source not being in sync. That's why we had no bug reports after making this mode default. >=20 > I think a better approach is to simply have a verb in qemu-ga to set/ge= t > 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 serie= s. That's not that easy in legacy guests, even more when they aren't Linux. >=20 > I don't think messing around with this stuff belongs in the QEMU clock > layer though. It's really not messing, the impact is almost minimal. Let's focus on the real big pieces first and then see what CLOCK_HOST actually contributes. That also means you should split up you patches a bit more, already for better bisectability. Jan --------------enigE6802152ADE18FB42194A047 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/ iEYEARECAAYFAk5S6uEACgkQitSsb3rl5xQc4gCfSZQLouuacRCflFU+QaPA1AEB nD0AoKFHSxBpjVgGnEoFr2h/e2/jLCVE =v09D -----END PGP SIGNATURE----- --------------enigE6802152ADE18FB42194A047--