From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL8Tq-0007wj-EO for qemu-devel@nongnu.org; Thu, 07 Jul 2016 08:32:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bL8Tl-0001hg-G5 for qemu-devel@nongnu.org; Thu, 07 Jul 2016 08:32:34 -0400 Received: from 7.mo69.mail-out.ovh.net ([46.105.50.32]:50657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL8Tl-0001gr-4K for qemu-devel@nongnu.org; Thu, 07 Jul 2016 08:32:29 -0400 Received: from player779.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id 583121010C68 for ; Thu, 7 Jul 2016 14:32:26 +0200 (CEST) Date: Thu, 7 Jul 2016 14:32:18 +0200 From: Greg Kurz Message-ID: <20160707143218.1937a548@bahia.lan> In-Reply-To: <20160707005728.GE14675@voom.fritz.box> References: <1467795561-1007-1-git-send-email-bharata@linux.vnet.ibm.com> <1467795561-1007-4-git-send-email-bharata@linux.vnet.ibm.com> <20160706140114.2ff04caf@172-15-179-184.lightspeed.austtx.sbcglobal.net> <20160706142101.GG25522@in.ibm.com> <20160707005728.GE14675@voom.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/GIrf8bDK6p_JKgIV4CcZ_9v"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [RFC PATCH v1 3/5] spapr: Implement CPUClass::get_migration_id() for PowerPC CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Bharata B Rao , Igor Mammedov , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, nikunj@linux.vnet.ibm.com, pbonzini@redhat.com --Sig_/GIrf8bDK6p_JKgIV4CcZ_9v Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 7 Jul 2016 10:57:28 +1000 David Gibson wrote: > On Wed, Jul 06, 2016 at 07:51:01PM +0530, Bharata B Rao wrote: > > On Wed, Jul 06, 2016 at 02:01:14PM +0200, Igor Mammedov wrote: =20 > > > On Wed, 6 Jul 2016 14:29:19 +0530 > > > Bharata B Rao wrote: > > > =20 > > > > cpu_index is used as migration_id by default. For machine type > > > > versions that set use-migration-id property, cpu_dt_it is returned. > > > >=20 > > > > Signed-off-by: Bharata B Rao > > > > --- > > > > target-ppc/translate_init.c | 12 ++++++++++++ > > > > 1 file changed, 12 insertions(+) > > > >=20 > > > > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_ini= t.c > > > > index efd6b88..9ca2f5e 100644 > > > > --- a/target-ppc/translate_init.c > > > > +++ b/target-ppc/translate_init.c > > > > @@ -10359,6 +10359,17 @@ static gchar *ppc_gdb_arch_name(CPUState *= cs) > > > > #endif > > > > } > > > > =20 > > > > +static int ppc_cpu_get_migration_id(CPUState *cs) > > > > +{ > > > > + PowerPCCPU *cpu =3D POWERPC_CPU(cs); > > > > + > > > > + if (cs->use_migration_id) { > > > > + return (int) cpu->cpu_dt_id; =20 > > > Could cpu_dt_id have value bigger than 32bit int? If yes, it's not sa= fe > > > to do so, that's the reason why I'm going to use index in possible_cp= us > > > on ARM and for the sake of uniformity do the same for x86 (even though > > > it's possible to use 32bit APIC ID). =20 > >=20 > > For the existing max_cpus limit, 32 bit should be fine, but obviously > > that is not good and future safe. =20 >=20 > I think we should be OK. The hardware IDs these are modelled on are > 32-bit - I'm pretty sure #address-cells in /cpus is 1, not 2. >=20 > And even with a lot of wastage for alignment gaps of various sorts, > we're a *long* way off from supporting 4 billion cpus... >=20 Indeed ! Even in the "worst" case, which is running a guest with 1 thread per core on a POWER8 host with full cores (8 HW threads), the current maxim= um value for cpu_dt_id is 254 * 8 =3D=3D 2032 :) > > I had a brief look at the implementation around possible_cpus in > > x86, let me see if I can do something similar for generating stable > > ids for PowerPC. I thought device tree ID would be our stable id, but > > that being 64 bit and migration code requiring 32 bit value isn't > > helping :( > >=20 > > Regards, > > Bharata. > > =20 >=20 --Sig_/GIrf8bDK6p_JKgIV4CcZ_9v Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAld+S9IACgkQAvw66wEB28J/wQCfRfbB/bhrSctcwmxSa9N8YK5x 8NAAn3t/05BcUYZKs6CLS+M+GyXeGZtl =jr+L -----END PGP SIGNATURE----- --Sig_/GIrf8bDK6p_JKgIV4CcZ_9v--