aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Huth <thuth@redhat.com>2016-08-09 19:00:01 +0200
committerDavid Gibson <david@gibson.dropbear.id.au>2016-08-10 13:12:20 +1000
commitd11b268e1765e8878c1150d463b9f6dc3a8d4456 (patch)
treeea7b8cf01e2fbe97664b8e0d224bd011c8347fc6
parent9c83fc2e8e1630e4d0fb10055563844b6e2cf2e0 (diff)
downloadqemu-d11b268e1765e8878c1150d463b9f6dc3a8d4456.zip
qemu-d11b268e1765e8878c1150d463b9f6dc3a8d4456.tar.gz
qemu-d11b268e1765e8878c1150d463b9f6dc3a8d4456.tar.bz2
ppc/kvm: Register also a generic spapr CPU core family type
There is a regression with the "-cpu" parameter 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. Let's fix it by supporting a CPU family type for the spapr-cpu-core on KVM, too. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1363812 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
-rw-r--r--target-ppc/kvm.c7
1 files changed, 5 insertions, 2 deletions
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 82b1df9..dcb68b9 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -2409,8 +2409,11 @@ static int kvm_ppc_register_host_cpu_type(void)
type_info.class_init = NULL;
type_register(&type_info);
g_free((void *)type_info.name);
- type_info.instance_size = 0;
- type_info.instance_init = NULL;
+
+ /* Register generic spapr CPU family class for current host CPU type */
+ type_info.name = g_strdup_printf("%s-"TYPE_SPAPR_CPU_CORE, dc->desc);
+ type_register(&type_info);
+ g_free((void *)type_info.name);
#endif
return 0;