| Message ID | 1470734229-10832-6-git-send-email-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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;
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> --- target-ppc/kvm.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)