From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNwWV-0007ki-LC for qemu-devel@nongnu.org; Tue, 26 Jan 2016 00:50:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNwWR-0004uy-DF for qemu-devel@nongnu.org; Tue, 26 Jan 2016 00:50:39 -0500 Date: Tue, 26 Jan 2016 16:51:20 +1100 From: David Gibson Message-ID: <20160126055120.GD16692@voom.fritz.box> References: <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> <20160118045113.GL9301@voom.fritz.box> <56A5B712.9070808@ilande.co.uk> <20160125111008.GG32205@voom.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xm/fll+QQv+hsKip" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-ppc] Migrating decrementer (was: Re: [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: BALATON Zoltan Cc: amit.shah@redhat.com, qemu-ppc@nongnu.org, Mark Cave-Ayland , qemu-devel@nongnu.org, quintela@redhat.com --Xm/fll+QQv+hsKip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 25, 2016 at 06:20:21PM +0100, BALATON Zoltan wrote: > On Mon, 25 Jan 2016, David Gibson wrote: > >Remember, we only ever compute the guest timebase value at the moment > >the guest requests it - actually maintaining a current timebase value > >makes sense in hardware, but would be nuts in software. > > > >The timebase is a function of real, wall-clock time, and the migration > >destination has a notion of wall-clock time without reference to the > >source. > > > >So what you need to transmit for migration is enough information to > >compute the guest timebase from real-time - essentially just an offset > >between real-time and the timebase. >=20 > I don't know anything about all this but if I understand your conversation > correctly then you don't really need an offset between real-time and > timebase. That would be true assuming the source and destination has the > same real-time but that's not necessarily true. No, it's not necessarily true, but if it's not that's not really our problem to deal with. We do ensure that the guest timebase doesn't go backwards in this situation, but if the source and destination hosts don't have synchronized time, the guest real time may jump. But since we have no idea whether the source or destination had a better notion of real-time, we can't really do any better. > What would be needed is an > offset between source timebase and destination's real time. That is, besi= des > the offset on the source you would also need to work out the difference in > the "real-time" on the source and destination and correct the transferred > offset with this after migration. Yeah, that's not really possible in the current migration model. Nor is it something that's really qemu's job. > Is this handled somehow in QEMU (for example by doing some message exchan= ge > to establish the clock difference between the source and destination duri= ng > migration) or is it assumed that migration always needs synchronised cloc= ks > done by some external means? Migration itself doesn't need synced clocks, but if the hosts' real-time isn't well behaved, you can't really expect the guest's real time to be well behaved. --=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 --Xm/fll+QQv+hsKip Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWpwlYAAoJEGw4ysog2bOS088QAJvsHWEnpZuZWgqQ0CWRRuYY 8kCNIAc5s56cZxS3NPEBg9l1k4TlYGUCietFhQy4Z8GlqhL2BCANgs4zb7MA0Z7G Yv+qHp6386662tpy/v1TPWupdGzSCHvaYZ5R13IJBrg+YPBhhJp0vJ9noaLIktaB CEYU1Lr+xx7I2Ensc0ln8yjgZYatD+W8lFISCYgIcBSAzRQjUVu7De4opITEYjvn rL+grnrCEsQ88gUDh/OobR1vpclTBYeJLRAS8INkQg1UdSjTqaVDmkIRkmgD2ovI 4h5GMF8vOtUgsDkq6VLUhSV11zQrDyo9DzmMMwjFEvjpK1K+bS1bD+/ZCJqdfsk0 9OUww7xkgKW0kkrKz5zebfiII70vzvR3KkaQjKChdV+7mYT50SK9f9zSQOeqq4jW lkLRxAk2vSOopVTVVv4jJSI9b1iyWopHFvW3FdiX5haYED2w/jyMzMg+BGvL4mPT NiTRxV8YCFiQXhy6QBn5togLbvWnJvSJgHANFTP3+3TJRRuRCmDSXAMhpfG0eFwo QrahBQWqayIPGw9ZO0TFo89jpcjPX4xeD7ILLmHZ90WjeBg7p+1gWzf2WUgIMJ0+ wNSHPT7Js7idFONctdKOws/UE1Ys3uay7lcZ6onQ4C798xER+QdZRG87YT/Rt66L 2NqBFu0uK9H8PBrKOn0O =nk2z -----END PGP SIGNATURE----- --Xm/fll+QQv+hsKip--