From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0ACw-0002ou-3C for qemu-devel@nongnu.org; Fri, 28 Oct 2016 12:40:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0ACs-0005v3-US for qemu-devel@nongnu.org; Fri, 28 Oct 2016 12:40:42 -0400 Received: from 8.mo68.mail-out.ovh.net ([46.105.74.219]:50951) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c0ACs-0005uV-Od for qemu-devel@nongnu.org; Fri, 28 Oct 2016 12:40:38 -0400 Received: from player788.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id F242CA228 for ; Fri, 28 Oct 2016 18:40:35 +0200 (CEST) References: <1477620301-24822-1-git-send-email-david@gibson.dropbear.id.au> From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Message-ID: Date: Fri, 28 Oct 2016 18:40:24 +0200 MIME-Version: 1.0 In-Reply-To: <1477620301-24822-1-git-send-email-david@gibson.dropbear.id.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] powernv: CPU compatibility modes don't make sense for powernv List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: benh@kernel.crashing.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 10/28/2016 04:05 AM, David Gibson wrote: > powernv has some code (derived from the spapr equivalent) used in devic= e > 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 > Hi C=C3=A9dric, I'd appreciate it if you can double check my reasoning > here. This patch gets powernv out of the way of a bunch of > compatibility mode cleanups I have in the works. It makes perfect sense. The "cpu-version" property is for PAPR, not for O= PAL. hostboot and skiboot put SPR_PVR in this property.=20 I will be careful using 'CPU_CORE(pc)->nr_threads' in the ICP patches als= o.=20 Reviewed-by: C=C3=A9dric Le Goater Thanks, C. >=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; > 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