From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bX5Cb-0005d9-QC for qemu-devel@nongnu.org; Tue, 09 Aug 2016 07:28:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bX5CX-000552-IK for qemu-devel@nongnu.org; Tue, 09 Aug 2016 07:28:08 -0400 Message-ID: <1470742079.2264.28.camel@redhat.com> From: Andrea Bolognani Date: Tue, 09 Aug 2016 13:27:59 +0200 In-Reply-To: <1470734229-10832-1-git-send-email-thuth@redhat.com> References: <1470734229-10832-1-git-send-email-thuth@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for-2.7 0/5] spapr: Fix regression in CPU alias handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth , David Gibson , qemu-ppc@nongnu.org Cc: Alexander Graf , qemu-devel@nongnu.org, bharata@linux.vnet.ibm.com On Tue, 2016-08-09 at 11:17 +0200, Thomas Huth wrote: > There is a regression with the "-cpu" parameter which has been > introduced by the spapr CPU hotplug code: We used to allow to specify > a "CPU family" name with the "-cpu" parameter when running on KVM so > that the user does not need to know the gory details of the exact > CPU version of the host CPU. For example, it was possible to > use "-cpu POWER8" on a POWER8E host CPU. This behavior does not > work anymore with the new hot-pluggable spapr-cpu-core types. > Since libvirt already heavily depends on the old behavior, this > is quite a severe regression in the QEMU parameter interface, thus > I think these patches should still go into 2.7 if possible, to avoid > that we break the "upper layers" with the final 2.7 release. >=C2=A0 > This patch series fixes the regression (and two more minor bugs) > by registering a family type for the spapr-cpu-core type, too > (see the last patch). However, since that name clashes with the > alias types that have been defined in spapr_cpu_core.c, we first > have to introduce there a better way to handle CPU aliases (see > the first two patches). > The third patch fixes a small memory leak along the way, and > the fourth patch makes sure that we do not mess up the generic > CPU family type registration anymore (which was another regression > introduced with the spapr CPU hotplug code). >=C2=A0 > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=3D1363812 >=C2=A0 > Thomas Huth (5): >=C2=A0=C2=A0=C2=A0ppc: Introduce a function to look up CPU alias strings >=C2=A0=C2=A0=C2=A0hw/ppc/spapr: Look up CPU alias names instead of hard-= coding the >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0aliases >=C2=A0=C2=A0=C2=A0hw/ppc/spapr: Do not leak the memory of the type strin= g >=C2=A0=C2=A0=C2=A0ppc/kvm: Do not mess up the generic CPU family registr= ation >=C2=A0=C2=A0=C2=A0ppc/kvm: Register also a generic spapr CPU core family= type >=C2=A0 >=C2=A0=C2=A0hw/ppc/spapr.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A03 ++- >=C2=A0=C2=A0hw/ppc/spapr_cpu_core.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| 38 ++= +++++++++++++++++++----------------- >=C2=A0=C2=A0target-ppc/cpu.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A01 + >=C2=A0=C2=A0target-ppc/kvm.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0| 19 +++++++++++-------- >=C2=A0=C2=A0target-ppc/translate_init.c | 13 +++++++++++++ >=C2=A0=C2=A05 files changed, 48 insertions(+), 26 deletions(-) Tested-By: Andrea Bolognani --=C2=A0 Andrea Bolognani / Red Hat / Virtualization