From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL1lm-0005U5-5d for qemu-devel@nongnu.org; Sun, 17 Jan 2016 23:50:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL1lk-0006Zb-UC for qemu-devel@nongnu.org; Sun, 17 Jan 2016 23:50:22 -0500 Date: Mon, 18 Jan 2016 15:51:13 +1100 From: David Gibson Message-ID: <20160118045113.GL9301@voom.fritz.box> References: <1452104533-8516-1-git-send-email-mark.cave-ayland@ilande.co.uk> <1452104533-8516-5-git-send-email-mark.cave-ayland@ilande.co.uk> <568F235B.1010506@ozlabs.ru> <568FC5FF.9070606@ilande.co.uk> <569302E7.4080404@ozlabs.ru> <20160111045519.GE22925@voom.redhat.com> <56935D3A.1030709@ilande.co.uk> <20160112024421.GH22925@voom.redhat.com> <56993062.4030604@ilande.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t5NgoZwlhlUmGr82" Content-Disposition: inline In-Reply-To: <56993062.4030604@ilande.co.uk> Subject: Re: [Qemu-devel] [PATCH 4/4] target-ppc: ensure we include the decrementer value during migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland Cc: quintela@redhat.com, Alexey Kardashevskiy , qemu-devel@nongnu.org, agraf@suse.de, qemu-ppc@nongnu.org, amit.shah@redhat.com --t5NgoZwlhlUmGr82 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 15, 2016 at 05:46:10PM +0000, Mark Cave-Ayland wrote: > On 12/01/16 02:44, David Gibson wrote: >=20 > >>> In other words, isn't this just skipping the decrementer interrupts at > >>> the qemu level rather than the guest level? > >>> > >>> It seems that instead we should be reconstructing the decrementer on > >>> the destination based on an offset from the timebase. > >> > >> Well I haven't really looked at how time warping works during in > >> migration for QEMU, however this seems to be the method used by > >> hw/ppc/ppc.c's timebase_post_load() function but my understanding is > >> that this isn't currently available for the g3beige/mac99 machines? > >=20 > > Ah.. yes, it looks like the timebase migration stuff is only hooked in > > on the pseries machine type. As far as I can tell it should be > > trivial to add it to other machines though - it doesn't appear to rely > > on anything outside the common ppc timebase stuff. > >=20 > >> Should the patch in fact do this but also add decrementer support? And > >> if it did, would this have a negative effect on pseries? > >=20 > > Yes, I think that's the right approach. Note that rather than > > duplicating the logic to adjust the decrementer over migration, it > > should be possible to encode the decrementer as a diff from the > > timebase across the migration. > >=20 > > In fact.. I'm not sure it ever makes sense to store the decrementer > > value as a direct value, since it's constantly changing - probably > > makes more sense to derive it from the timebase whenever it is needed. > >=20 > > As far as I know that should be fine for pseries. I think the current > > behaviour is probably technically wrong for pseries as well, but the > > timing code of our Linux guests is robust enough to handle a small > > displacement to the time of the next decrementer interrupt. >=20 > I've had a bit of an experiment trying to implement something suitable, > but I'm not 100% certain I've got this right. >=20 > >From the code my understanding is that the timebase is effectively > free-running and so if a migration takes 5s then you use tb_offset to > calculate the difference between the timebase before migration, and > subsequently apply the offset for all future reads of the timebase for > the lifetime of the CPU (i.e. the migrated guest is effectively living > at a point in the past where the timebase is consistent). Um.. no. At least in the usual configuration, the timebase represents real, wall-clock time, so we expect it to jump forward across the migration downtime. This is important because the guest will use the timebase to calculate real time differences. However, the absolute value of the timebase may be different on the *host* between source and destination for migration. So what we need to do is before migration we work out the delta between host and guest notions of wall clock time (as defined by the guest timebase), and transfer that in the migration stream. On the destination we initialize the guest timebase so that the guest maintains the same realtime offset from the host. This means that as long as source and destination system time is synchronized, guest real-time tracking will continue correctly across the migration. We do also make sure that the guest timebase never goes backwards, but that would only happen if the source and destination host times were badly out of sync. --=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 --t5NgoZwlhlUmGr82 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWnG9BAAoJEGw4ysog2bOSQtYQAJU2QaWI9BnY2+HtN3U2Sn8I ucgv50IUMwdkTiq0me01VD9RY12nRlPuR3zTKVKVkgA2d++wMnz8Ow5zkWv6jo9N EU3ZQWGGEn0LtVhCeotidOhXM1+39i8EW5SUCzR5uFWDRBwBTAA0iNJ5fFGksJH8 gZ57cqRL1sLepkPq90Z1MMec/sl1WWtttXHj/Lk0QVrO6aAiH+KXzfBxRUBsx7YI AW0DBBhw/QKk1Gy5/5n/D758e4oV6MjjHTs2ldMbv/KuH9Wn25l2C4/8MfHHNMbE VBk2/Bsn5nt0Q+iMV6ZuA1Ff39EnkV4grxSEfNVVJZQEnaMYEMZl85nSsUaZwsjf kyV+tMIcYDpoIUSV0Qf4Ff3vW8CaT0peVSteoE4FRmwK5gAO3KK79KwNCOZnLTG0 rKnXXILUZYQLRoPlUCz4xUfBVhX106adBJykuR3jUeHTPPf99+lpQul2CErvrEkq KTcuPSDeSxi2X2hz62vkJSU0iMKI6SIB+8VgGSCOmpgxN7U/34Zp8CIGb6KMBTSM o2Qe3tL5F1HDbEI/xSoAVoBL8hbcFG++qgx3bz0wG00UHlQsvZyHF2zVF7yxEle0 PG/wyqn63U46INnEei2SF8iPOAfQlGPWlt2LfYxCpO51289iRwhOiUyz152FHyCm ITUB6uUp/JzARrA75vG4 =D4Ou -----END PGP SIGNATURE----- --t5NgoZwlhlUmGr82--