From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKLwF-00089F-Tz for qemu-devel@nongnu.org; Fri, 13 Sep 2013 01:29:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKLwB-0001Zn-Sc for qemu-devel@nongnu.org; Fri, 13 Sep 2013 01:29:03 -0400 Date: Fri, 13 Sep 2013 15:20:39 +1000 From: David Gibson Message-ID: <20130913052039.GB28840@voom.redhat.com> References: <1378388164.4321.176.camel@pasglop> <17161D2C-8CAE-40D9-B4E2-EBCE69D69FAA@suse.de> <522891C2.8020107@suse.de> <1378391219.4321.191.camel@pasglop> <522D3534.6070207@ozlabs.ru> <2D3C9633-E8AE-4290-910A-5656E19B02A6@suse.de> <522D6383.8050700@ozlabs.ru> <7B3E1C54-B3E4-4E86-ACC0-2824199BA154@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: <7B3E1C54-B3E4-4E86-ACC0-2824199BA154@suse.de> Subject: Re: [Qemu-devel] [RFC PATCH] spapr: support time base offset migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Alexey Kardashevskiy , "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , Paolo Bonzini , Paul Mackerras , Andreas =?iso-8859-1?Q?F=E4rber?= --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 09, 2013 at 08:06:53AM +0200, Alexander Graf wrote: >=20 >=20 > Am 09.09.2013 um 07:58 schrieb Alexey Kardashevskiy : >=20 > > On 09/09/2013 03:50 PM, Alexander Graf wrote: > >>=20 > >>=20 > >> Am 09.09.2013 um 04:40 schrieb Alexey Kardashevskiy : > >>=20 > >>> On 09/06/2013 01:11 AM, Alexander Graf wrote: > >>>>=20 > >>>> On 05.09.2013, at 16:26, Benjamin Herrenschmidt wrote: > >>>>=20 > >>>>> On Thu, 2013-09-05 at 16:14 +0200, Andreas F=E4rber wrote: > >>>>>=20 > >>>>>> Are you thinking of POWER8 having a different frequency than POWER= 8 in > >>>>>> compat mode? Because migration from one -cpu to another is not sup= ported > >>>>>> elsewhere. > >>>>>>=20 > >>>>>> Even if we want to migrate from one POWER7 revision to another, we > >>>>>> should let the destination use the revision of the source (guest A= BI!), > >>>>>> via property if need be. Anything else will lead to confusion as t= o what > >>>>>> is supported and what is not. That -cpu host is the default for > >>>>>> convenience shouldn't relieve admins/libvirt to think about sensib= le > >>>>>> setups like they have to on x86. > >>>>>=20 > >>>>> Besides POWER8 uses 512Mhz too :-) It's been architected so it's > >>>>> unlikely to change from now on. > >>>>=20 > >>>> Ok, ditch the tb frequency then. We can always default to 512Mhz whe= n it's absent. > >>>=20 > >>>=20 > >>> QEMU uses what kvmppc_get_tbfreq() returns. And ppc_tb_t carries this > >>> value. It does not use 512MHz automatically but migration should alwa= ys > >>> assume 512MHz :-/ > >>>=20 > >>> If we remove it, I would like to add assert(tb_freq!=3D512MHz) into > >>> timebase_pre_save() and timebase_post_load(), is that ok? > >>=20 > >> Good point. This would break TCG migration, right? > >=20 > >=20 > > In TCG we do not need any timebase offset at all, the time should migra= te > > as is, no? :) >=20 > I hope so, but we need to make sure we don't assert() in that case :). Hrm.. that doesn't sound right. Whether you have KVM or TCG, what you need in the migration stream is enough data points that you can deduce the guest timebase from the host real time. On KVM that translates into a diff between guest and host timebase, but on TCG you'll need to implement that differently > >=20 > > It could break something like power5 migration under PR KVM, do not kno= w... >=20 > Well, today we don't support full migration with PR KVM yet - IIRC we don= 't have access to all state. But that may change in the future. >=20 > I think it's ok to restrict live migration to machines with the same > tb frequency when kvm is enabled. Whether you implement it through a > hardcoded 512Mhz or through a timebase value that gets live migrated > and then compared is up to you - both ways work for me :). I don't think it's possible to allow KVM migration between hosts of different tb frequency. But I think encoding the frequency in the stream and verifying it is a better option. It might be useful for migration on 970, and it might be useful for TCG migration and it might be useful for TCG<->KVM migration. (For a TCG migration destination you *can* potentially set the tb frequency according to what you're told). --=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 --Pd0ReVV5GZGQvF3a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJSMqCnAAoJEGw4ysog2bOSnn4QAMxGRfXfnGhPUD8Q50P1XMmA GX3W7YunyzX6iaqgVlq8Fqu3O6TAqLeb7sggbL/6kGPi7tywvbsGMuHuNRVzUDTl Ci7v5lmbQtmLbjAinLlwxniX0KyBkKo1wyFH1TfeVWl/JHlBt0rnBOMuxVTLi8Vq Zfuh5qd4QZL/x2aDwAV63lwhFE0LzCHnKGPV5jhwlGpIRUWcQyCKm9Utww3zBp7c 4WvsIrX5fUp0pIvRxM/TaUzD2v2vpWIq+4E4ds5+jDuSqWzes/7GXOVKyDadaQBE kwo9Wf1VQM8C+w+dQduSn4k2XaI+jN6XQyQXwHUBklnapvGpTlxIHBnKoRH7LuEH 3xskRJfo4QJxohitRVeBdml7Rz1nLppCNtg9CwMTdAp4xqE3DqQGtrwF9qbcHJaN EsV/P9uBypLZmuAoWXNSHf959Rk/4dSXT4oDLl0KmZHCkfYE+FDq/OjUpjbrKAZS exMy4CWYNN6Gys9Vx1MR7mbSzWvjmSS1XG/jC2Cb2Lz3mBh8T72pfFzERTPKX6zC AdNQrJkov2iiTkg+oCVeZH/E2lMqY4N4tGWqElSvUJgJsaPgvwWNMCsjusIGqoAw S356dALJjpHhxyo95s1jFfQWzGGA5D04OLEW5zknIJ+0tnhTSi3Hhi8iMVRrBbEt yqdX14XF0/zOSEgx8wm0 =gqkn -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a--