From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahpNl-0002Cx-Vy for qemu-devel@nongnu.org; Sun, 20 Mar 2016 22:15:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahpNh-0004Oi-80 for qemu-devel@nongnu.org; Sun, 20 Mar 2016 22:15:49 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:43107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahpNg-0004NU-MA for qemu-devel@nongnu.org; Sun, 20 Mar 2016 22:15:45 -0400 Received: from localhost by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 21 Mar 2016 12:15:41 +1000 From: Alexey Kardashevskiy Date: Mon, 21 Mar 2016 13:14:02 +1100 Message-Id: <1458526442-2125-1-git-send-email-aik@ozlabs.ru> Subject: [Qemu-devel] [PATCH qemu v2] spapr/target-ppc/kvm: Only add hcall-instructions if KVM supports it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-ppc@nongnu.org Cc: Alexey Kardashevskiy , Alexander Graf , qemu-devel@nongnu.org, David Gibson ePAPR defines "hcall-instructions" device-tree property which contains code to call hypercalls in ePAPR paravirtualized guests. In general pseries guests should not be using this facility (as there is sPAPR interface) and this property should not be present in the device tree for pseries guests. However a while ago this interface was chosen to implement a hypervisor interface to speed up PR KVM guests and since then the property is always present in the device tree. All KVM guests use it at least to read features via the KVM_HC_FEATURES hypercall. The property is populated by the code returned from the KVM's KVM_PPC_GET_PVINFO ioctl; if not implemented in the KVM, QEMU writes there "li r3, -1; nop; nop; nop". If QEMU does not create the property, and the guest kernel is compiled with CONFIG_EPAPR_PARAVIRT (which is normally the case), there is exactly the same stub at @epapr_hypercall_start already. Rather than maintaining the property (which used to be BE only; then was fixed to be endian-agnostic) and confusing the guest (which might think there is ePAPR host while there is none), it makes sense not to create the property in the device tree in the first place if the host kernel does not implement it. This changes kvmppc_get_hypercall() to return 1 if the host kernel does not implement KVM_CAP_PPC_GET_PVINFO. The caller can use it to decide on whether to create the property or not. This changes the pseries machine to not create the property if KVM does not implement KVM_PPC_GET_PVINFO. In practice this means that from now on the property will not be created if either HV KVM or TCG is used. Signed-off-by: Alexey Kardashevskiy --- Changes: v2: * changed the commit log --- hw/ppc/spapr.c | 9 +++++---- target-ppc/kvm.c | 2 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index d0bb423..d43d6d9 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -497,10 +497,11 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base, * Older KVM versions with older guest kernels were broken with the * magic page, don't allow the guest to map it. */ - kvmppc_get_hypercall(first_cpu->env_ptr, hypercall, - sizeof(hypercall)); - _FDT((fdt_property(fdt, "hcall-instructions", hypercall, - sizeof(hypercall)))); + if (!kvmppc_get_hypercall(first_cpu->env_ptr, hypercall, + sizeof(hypercall))) { + _FDT((fdt_property(fdt, "hcall-instructions", hypercall, + sizeof(hypercall)))); + } } _FDT((fdt_end_node(fdt))); } diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index 776336b..e5183db 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -2001,7 +2001,7 @@ int kvmppc_get_hypercall(CPUPPCState *env, uint8_t *buf, int buf_len) hc[2] = cpu_to_be32(0x48000008); hc[3] = cpu_to_be32(bswap32(0x3860ffff)); - return 0; + return 1; } static inline int kvmppc_enable_hcall(KVMState *s, target_ulong hcall) -- 2.5.0.rc3