From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYjdO-0006Wi-00 for qemu-devel@nongnu.org; Wed, 24 Feb 2016 19:18:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYjdJ-00051T-VN for qemu-devel@nongnu.org; Wed, 24 Feb 2016 19:18:21 -0500 Date: Thu, 25 Feb 2016 11:19:17 +1100 From: David Gibson Message-ID: <20160225001917.GR2808@voom.fritz.box> References: <20160118045113.GL9301@voom.fritz.box> <56A5B712.9070808@ilande.co.uk> <20160125111008.GG32205@voom.redhat.com> <56A7F3B7.3080908@ilande.co.uk> <20160201005218.GY23043@voom.redhat.com> <56B13EB4.9000309@ilande.co.uk> <20160203045926.GH15080@voom.fritz.box> <56CCCEAD.70805@ilande.co.uk> <20160224004738.GC2808@voom.fritz.box> <87mvqql27q.fsf@emacs.mitica> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReoOxgzMK1Uj1WV+" Content-Disposition: inline In-Reply-To: <87mvqql27q.fsf@emacs.mitica> Subject: Re: [Qemu-devel] Migrating decrementer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Alexey Kardashevskiy , Mark Cave-Ayland , agraf@suse.de, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, amit.shah@redhat.com --ReoOxgzMK1Uj1WV+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 24, 2016 at 01:31:05PM +0100, Juan Quintela wrote: > David Gibson wrote: > > On Tue, Feb 23, 2016 at 09:27:09PM +0000, Mark Cave-Ayland wrote: > >> On 03/02/16 04:59, David Gibson wrote: > >>=20 > >> >> Going back to your earlier email you suggested that the host timeba= se is > >> >> always continuously running, even when the guest is paused. But then > >> >> resuming the guest then the timebase must jump in the guest regardl= ess? > >> >> > >> >> If this is the case then this is the big difference between TCG and= KVM > >> >> guests: TCG timebase is derived from the virtual clock which solves= the > >> >> problem of paused guests during migration. For example with the exi= sting > >> >> migration code, what would happen if you did a migration with the g= uest > >> >> paused on KVM? The offset would surely be wrong as it was calculate= d at > >> >> the end of migration. > >> >=20 > >> > So there are two different cases to consider here. Once is when the > >> > guest is paused incidentally, such as during migration, the other is > >> > when the guest is explicitly paused. > >> >=20 > >> > In the first case the timebase absolutely should keep running (or > >> > appear to do so), since it's the primary source of real time for the > >> > guest. > >>=20 > >> I'm not sure I understand this, since if the guest is paused either > >> deliberately or incidentally during migration then isn't the timebase > >> also frozen? Or is it external to the CPU? > > > > I don't really understand the question. Migration has no equivalent > > in real hardware, so there's no "real" behaviour to mimic. If we > > freeze the TB during migration, then the guest's clock will get out of > > sync with wall clock time, and in a production environment that's > > really bad. So no, we absolutely must not freeze the TB during > > migration. > > > > When the guest has been explicitly paused, there's a case to be made > > either way. >=20 > If this is the case, can't we just change the device to just read the > clock from the host at device insntantiation and call it a day? That's not quite enough, because although the timebase advances in real time, it will have an offset from realtime that varies boot to boot. > (* Notice that I haven't seen the previous discussion *) >=20 > On migration, having a post-load function that just loads the right > value for that device should work. Or if we want to make it work for > pause/cont, we should have a notifier to be run each time "cont" is > issued, and put a callback there? Right. This is basically what we already do on pseries: in pre_save we store both the timebase value and the current real time. In post_load we again check the real time, look at the difference from the value in the migration stream and advance the TB to match. > Or I am missing something improtant? >=20 > > > >> > In the second case, it's a bit unclear what the right thing to do is. > >> > Keeping the tb running means accurate realtime, but stopping it is > >> > often better for debugging, which is one of the main reasons to > >> > explicitly pause. > >> >=20 > >> > I believe spapr on KVM HV will keep the TB going, but the TSC on x86 > >> > will be stopped. > >>=20 > >> Is this from a guest-centric view, i.e. if I pause a VM and wait 20 mi= ns > >> then when the guest resumes the timebase will jump forward by 20 mins > >> worth of ticks? > > > > Yes, that's correct. >=20 > I.e. my proposal fixes this? > If you want ot make it really, really "classy", you can look at the mess > we have on x86 to introduce ticks "slewly" for windos 95 (and XP?) > during a while, but I don't think that solution would work for 20mins of > ticks :p >=20 > Later, Juan. >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --ReoOxgzMK1Uj1WV+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWzkiFAAoJEGw4ysog2bOSA9wP/22LsSK6MXI4EitKZYXWZ/eV qaRMM97p1LSEYjI0ZDjf1NDqg5M03mX0KUyyShvdBQuXFK1t/FzPQYssOs9TwLCF J0K4g53mKapNqyvq8xOW6huevbSLAhcSD7+OdgVsUcPa0g47v4EyFkomH03Gi36n WLjzpkZc+zXahMYHwngaUDKnz4j06TOXRU4FIQgY4Ws5NKdQ/TAQEOGFTpdBG4QR jikJf14O1qPC9oLCkmNRQ+SiNU0RlkbWx7aAcvmK1WpsuWpNwtDS5n4TSdVBsrmD gNh1XgQ07XDb+ugWsUtwU4MiZotk8ewThSVtP8UPYNoFmv4D8KwFZau0nvO0yfC8 Fcf3B6Z32iA+8l43z3DDB1mIa/pUJ4s01J+UwtaX4bwwMPFctrIszX9YLs8YX6v3 X4cIfN2BhW1MxaIDrlwGCUPVqVyeGH9RJpkxrZDpMdq04qgSSqgmW+yxLGbj+W3s KmJ80TiHY7FpIRQYaJff1QoN9NBKCv0AA1ViCtX5PL9PiUGInqloopHBZTIgqvZb 8Zo+MMiCsQqSjaScw8Z8S24qxqJUdtPfz2Hayw76GoiB2drtZNMfPedSa8KpdMjv vIUHaqoPmUX+ys63Rw8Vx6usgSO3TbRckbMDc+0jXs49uuY5kOY1ckMB4D8/8kXU GFHCO7Xmnut0yo6SbZhE =YgH1 -----END PGP SIGNATURE----- --ReoOxgzMK1Uj1WV+--