From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c187Q-000235-VR for qemu-devel@nongnu.org; Mon, 31 Oct 2016 04:39:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c187O-00046z-Lg for qemu-devel@nongnu.org; Mon, 31 Oct 2016 04:39:00 -0400 Date: Mon, 31 Oct 2016 19:38:44 +1100 From: David Gibson Message-ID: <20161031083844.GS18226@umbus.fritz.box> References: <1477825928-10803-1-git-send-email-david@gibson.dropbear.id.au> <1477825928-10803-3-git-send-email-david@gibson.dropbear.id.au> <8427dbf1-7c0a-7db5-bc59-3a37a8b1b32e@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4ZVTVymsHR1TEBjP" Content-Disposition: inline In-Reply-To: <8427dbf1-7c0a-7db5-bc59-3a37a8b1b32e@redhat.com> Subject: Re: [Qemu-devel] [RFC 02/17] powernv: CPU compatibility modes don't make sense for powernv List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: nikunj@linux.vnet.ibm.com, aik@ozlabs.ru, mdroth@linux.vnet.ibm.com, lvivier@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org --4ZVTVymsHR1TEBjP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 31, 2016 at 08:46:55AM +0100, Thomas Huth wrote: > On 30.10.2016 12:11, David Gibson wrote: > > powernv has some code (derived from the spapr equivalent) used in device > > tree generation which depends on the CPU's compatibility mode / logical > > PVR. However, compatibility modes don't make sense on powernv - at lea= st > > not as a property controlled by the host - because the guest in powernv > > has full hypervisor level access to the virtual system, and so owns the > > PCR (Processor Compatibility Register) which implements compatiblity mo= des. > >=20 > > Signed-off-by: David Gibson > > --- > > hw/ppc/pnv.c | 6 +----- > > 1 file changed, 1 insertion(+), 5 deletions(-) > >=20 > > diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c > > index 82276e0..6af3424 100644 > > --- a/hw/ppc/pnv.c > > +++ b/hw/ppc/pnv.c > > @@ -110,7 +110,7 @@ static void powernv_create_core_node(PnvChip *chip,= PnvCore *pc, void *fdt) > > CPUState *cs =3D CPU(DEVICE(pc->threads)); > > DeviceClass *dc =3D DEVICE_GET_CLASS(cs); > > PowerPCCPU *cpu =3D POWERPC_CPU(cs); > > - int smt_threads =3D ppc_get_compat_smt_threads(cpu); > > + int smt_threads =3D CPU_CORE(pc)->nr_threads; >=20 > ppc_get_compat_smt_threads() also checks kvmppc_smt_threads() ... as > long as we do not run the powernv architecture with KVM PR, your change > should be OK, but if we support that one day, we might need to check > kvmppc_smt_threads() here, too? No, actually. I covered this when I posted this patch standalone earlier, but forgot to add it to the commit message. If nr_threads exceeds kvmppc_smt_threads() then things are already broken, and clamping the value here isn't going to save us. >=20 > > CPUPPCState *env =3D &cpu->env; > > PowerPCCPUClass *pcc =3D POWERPC_CPU_GET_CLASS(cs); > > uint32_t servers_prop[smt_threads]; > > @@ -206,10 +206,6 @@ static void powernv_create_core_node(PnvChip *chip= , PnvCore *pc, void *fdt) > > _FDT((fdt_setprop(fdt, offset, "ibm,pa-features", > > pa_features, sizeof(pa_features)))); > > =20 > > - if (cpu->cpu_version) { > > - _FDT((fdt_setprop_cell(fdt, offset, "cpu-version", cpu->cpu_ve= rsion))); > > - } > > - > > /* Build interrupt servers properties */ > > for (i =3D 0; i < smt_threads; i++) { > > servers_prop[i] =3D cpu_to_be32(pc->pir + i); > >=20 >=20 > Reviewed-by: Thomas Huth >=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 --4ZVTVymsHR1TEBjP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYFwMUAAoJEGw4ysog2bOSf6AP/A6ZS+yslDXNyq3XtrajObER Z8fGLcwY2vgMsLNFhy6bZ9zkkA2AavHmWdkoFXKF2i2RegMHEj1g/LorAqo9vSaZ TQ5KR5DO+UGYAlGiU0tfYS/gQA+8wCtCMXCpg6Kb9zhqEEcK5Nl780F2+4DVm4xL psg2DYkENGbJSo5IP16QP5Czs80YU+UBLQgg1pHuwQJk9B7IpF/odPquXV3F22Gw baGw0yOzdiAz6KjvkUqfYAaFhd3HId6D0N9+IC6xlSYzxyROm3Rz8AK5UAB4A6lK Hg34tdmEBwyMrI77+JKbq0vKxjIgy7sleUcsLPbUNZa+ebOuDTUbXQwsBFSr8B07 oitKmWzfVhm8yXXC9ajJxH+7d/mKrIO7Ti+ytvdW9Q+04/LanavvANx8AagYJuCY 0N+NkvP+JoFBYOZ2vWY1UdSATJQTqSraKe52GSAIzUkJWJHMnkrdJBD2Jg7MJ8/6 dAznTLkl4XIkCcFaf8PdFyNlyA6HYsbK2R7Mjz9iMtUaa+A9UnkpjxYz4BoW2JyP ZKTnwGv0nx5xDi+sZOP8fB7j7h8aa3e56YxI6imob5dgOTpXtIfsLCNKblridTmd odt3C1n0ksCwkLerv0KqSSwUevO/Obcfo+NYOxFwhcfv0eZOvHK/OZxhros+ai8s QeSuxlSIyVqUQyuIge5x =A2BM -----END PGP SIGNATURE----- --4ZVTVymsHR1TEBjP--