From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSR0a-0006Dy-Rh for qemu-devel@nongnu.org; Mon, 02 Mar 2015 09:07:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSR0X-0004kX-Ht for qemu-devel@nongnu.org; Mon, 02 Mar 2015 09:07:44 -0500 Message-ID: <54F46EAB.6090205@suse.de> Date: Mon, 02 Mar 2015 15:07:39 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1425169895-10783-1-git-send-email-afaerber@suse.de> <54F4678D.20909@suse.de> <54F468D5.2060407@suse.de> <54F46AF7.60209@suse.de> In-Reply-To: <54F46AF7.60209@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Revert "target-ppc: Create versionless CPU class per family if KVM" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , qemu-devel@nongnu.org Cc: Alexey Kardashevskiy , Paolo Bonzini , qemu-ppc , qemu-stable@nongnu.org, kvm Am 02.03.2015 um 14:51 schrieb Alexander Graf: > On 02.03.15 14:42, Andreas F=C3=A4rber wrote: >> Am 02.03.2015 um 14:37 schrieb Alexander Graf: >>> On 01.03.15 01:31, Andreas F=C3=A4rber wrote: >>>> This reverts commit 5b79b1cadd3e565b6d1a5ba59764bd47af58b271 to avoi= d >>>> double-registration of types: >>>> >>>> Registering `POWER5+-powerpc64-cpu' which already exists >>>> >>>> Taking the textual description of a CPU type as part of a new type n= ame >>>> is plain wrong, and so is unconditionally registering a new type her= e. >>>> >>>> Cc: Alexey Kardashevskiy >>>> Cc: qemu-stable@nongnu.org >>>> Signed-off-by: Andreas F=C3=A4rber >>> >>> Doesn't this break p8 support? >> >> Maybe, but p5 support was in longer and this is definitely a regressio= n >> and really really wrong. If you know a way to fix it without handing i= t >> back to the IBM guys for more thought, feel free to give it a shot. >=20 > I honestly don't fully remember what this was about. Wasn't this our > special KVM class that we use to create a compatible cpu type on the fl= y? No, the class I create on the fly is a few lines above: pvr_pcc =3D ppc_cpu_class_by_pvr(host_pvr); if (pvr_pcc =3D=3D NULL) { pvr_pcc =3D ppc_cpu_class_by_pvr_mask(host_pvr); } if (pvr_pcc =3D=3D NULL) { return -1; } type_info.parent =3D object_class_get_name(OBJECT_CLASS(pvr_pcc)); type_register(&type_info); So, if no matching class is returned, we never reach the offending code. Here, a second type with the same parent was being created in the kvm_ppc_register_host_cpu_type() function that is supposed to create that host CPU type. Why? The host CPU type by definition should already have the right PVR taken from the host. kvmppc_host_cpu_class_init(): /* Now fix up the class with information we can query from the host *= / pcc->pvr =3D mfpvr(); > Alexey, please take a look at it. Thanks, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=C3=BCrnberg)