From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: time does not move forward in HVM guests Date: Wed, 5 Jul 2017 09:25:58 +0200 Message-ID: <20170705072558.GA22677@aepfle.de> References: <20170704163326.GA22633@aepfle.de> <595CAA440200007800168975@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1775838350081471844==" Return-path: In-Reply-To: <595CAA440200007800168975@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============1775838350081471844== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 05, Jan Beulich wrote: > > clock_getres(CLOCK_MONOTONIC) indicates a resolution of 1ns. > But what's the implied meaning of resolution here? See below. I have no ide what the returned value is supposed to promise. > Or did you perhaps test with an older version, where the time > handling backports from master hadn't been there yet? It was weeks ago, and I have not seen it since then. I think it is fixed in one way or another. > > A workaround is booting the domU kernel with 'clocksource=3Dtsc nohz=3D= off=20 > > highres=3Doff'. > What clocksource does the system use by default? HPET? HPET would be really really slow. The default clocksource is "xen". > According to what the hypervisor tells the guest, vHPET > resolution is 16ns. That still wouldn't explain a steady value > over a period of 100ns, but it's at least a hint that what the > kernel tells you may not be what underlying (virtual) > hardware reports. If clocksource=3Dxen relies on the hypervisor, perhaps the kernel should be aware of it in some way. So far I have not checked where clock_getres gets its data. > Additionally - are all three options indeed required to work > around this, i.e. no pair out of the three is enough? Yes, otherwise the kernel would complain, forgot the exact error message. Olaf --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWVyUggAKCRBdQqD6ppg2 fvRbAKCmnzOu0XiWEb5Fqwkm59xK62jzrwCfc9reavvj3rFJSqniaCcEsbzj/PI= =VOqr -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- --===============1775838350081471844== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1775838350081471844==--