Re: [libvirt] [PATCH] cpu_ppc64: Add support for host-model on POWER9

On Thu, 2017-06-08 at 18:40 +0200, Andrea Bolognani wrote: Okay, I've tried again with upstream QEMU master (with your CPU compatibility patches applied on top), here are the results for both POWER8 and POWER9. <nothing> =========   * POWER8 (architected)   * POWER9 (raw) -cpu POWER8 ===========   * POWER8 (architected)   * qemu-system-ppc64: Register sync failed...     If you're using kvm-hv.ko, only "-cpu host" is possible     kvm_init_vcpu failed: Invalid argument -cpu POWER9 ===========   * qemu-system-ppc64: Register sync failed...     If you're using kvm-hv.ko, only "-cpu host" is possible     kvm_init_vcpu failed: Invalid argument   * qemu-system-ppc64: Register sync failed...     If you're using kvm-hv.ko, only "-cpu host" is possible     kvm_init_vcpu failed: Invalid argument -cpu host =========   * POWER8 (architected)   * POWER9 (raw) -cpu host,compat=power8 =======================   * POWER8 (architected)   * Unexpected error in ppc_set_compat() at target/ppc/compat.c:135:     qemu-system-ppc64: Compatibility PVR 0x0f000004 not valid for CPU     Aborted -cpu host,compat=power9 =======================   * Unexpected error in ppc_set_compat() at target/ppc/compat.c:135:     qemu-system-ppc64: Compatibility PVR 0x0f000005 not valid for CPU     Aborted   * Unexpected error in ppc_set_compat() at target/ppc/compat.c:135:     qemu-system-ppc64: Compatibility PVR 0x0f000005 not valid for CPU     Aborted AIUI, the fact that POWER9 is using raw mode rather than architected mode for all cases where the guest actually manages to boot is because compatibility modes are not enabled for early silicon; this is consistent with QEMU refusing to use the compatibility modes when explicitly asked to do so. However, the fact that '-cpu POWER9' can't be used on the POWER9 machine seems like a genuine bug. Even on POWER8, the error message is pretty misleading. Last but not least, using an unsupported compatibility mode results in QEMU abort()ing, which seems a bit excessive for a very reasonable guest configuration error. Do you want me to go ahead and file bugs for the last two items? --  Andrea Bolognani / Red Hat / Virtualization