From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c03Wy-00032u-Th for qemu-devel@nongnu.org; Fri, 28 Oct 2016 05:32:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c03Wt-0001eQ-W4 for qemu-devel@nongnu.org; Fri, 28 Oct 2016 05:32:56 -0400 Received: from 2.mo6.mail-out.ovh.net ([46.105.76.65]:47880) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c03Wt-0001e6-Q3 for qemu-devel@nongnu.org; Fri, 28 Oct 2016 05:32:51 -0400 Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id A581657276 for ; Fri, 28 Oct 2016 11:32:49 +0200 (CEST) Date: Fri, 28 Oct 2016 11:32:43 +0200 From: Greg Kurz Message-ID: <20161028113243.0a4e92d4@bahia> In-Reply-To: <1477620301-24822-1-git-send-email-david@gibson.dropbear.id.au> References: <1477620301-24822-1-git-send-email-david@gibson.dropbear.id.au> MIME-Version: 1.0 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: clg@kaod.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org On Fri, 28 Oct 2016 13:05:01 +1100 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 least > 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 mode= s. >=20 This makes a lot of sense indeed. > 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. >=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, P= nvCore *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; Not speaking of the PCR, this has also another effect since=20 ppc_get_compat_smt_threads() also take the KVM smt capability into account: int ret =3D MIN(cs->nr_threads, kvmppc_smt_threads()); Shouldn't you do the same here ? > 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_vers= ion))); > - } > - > /* Build interrupt servers properties */ > for (i =3D 0; i < smt_threads; i++) { > servers_prop[i] =3D cpu_to_be32(pc->pir + i);