From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3ruM-0006rG-Vm for qemu-devel@nongnu.org; Tue, 21 Aug 2012 13:06:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3ruK-0002gZ-VH for qemu-devel@nongnu.org; Tue, 21 Aug 2012 13:06:26 -0400 Received: from mail-gh0-f173.google.com ([209.85.160.173]:61109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3ruK-0002gN-Qy for qemu-devel@nongnu.org; Tue, 21 Aug 2012 13:06:24 -0400 Received: by ghrr17 with SMTP id r17so31193ghr.4 for ; Tue, 21 Aug 2012 10:06:24 -0700 (PDT) Sender: fluxion From: Michael Roth Date: Tue, 21 Aug 2012 12:05:37 -0500 Message-Id: <1345568757-14365-4-git-send-email-mdroth@linux.vnet.ibm.com> In-Reply-To: <1345568757-14365-1-git-send-email-mdroth@linux.vnet.ibm.com> References: <1345568757-14365-1-git-send-email-mdroth@linux.vnet.ibm.com> Subject: [Qemu-devel] [PATCH 03/23] ppc: Fix bug in handling of PAPR hypercall exits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: aliguori@us.ibm.com From: David Gibson Currently for powerpc, kvm_arch_handle_exit() always returns 1, meaning that its caller - kvm_cpu_exec() - will always exit immediately afterwards to the loop in qemu_kvm_cpu_thread_fn(). There's no need to do this. Once we've handled the hypercall there's no reason we can't go straight around and KVM_RUN again, which is what ret = 0 will signal. The only exception might be for hypercalls which affect the state of cpu_can_run(), however the only one that might do this is H_CEDE and for kvm that is always handled in the kernel, not qemu. Furtherm setting ret = 0 means that when exit_requested is set from a hypercall, we will enter KVM_RUN once more with a signal which lets the the kernel do its internal logic to complete the hypercall with out actually executing any more guest code. This is important if our hypercall also triggered a reset, which previously would re-initialize everything without completing the hypercall. This caused the kernel to get confused because it thought the guest was still in the middle of a hypercall when it has actually been reset. This patch therefore changes to ret = 0, which is both a bugfix and a small optimization. Signed-off-by: David Gibson Signed-off-by: Alexander Graf (cherry picked from commit 78e8fde26c032931ca2ae13bfc7c59e38afd17ee) Signed-off-by: Michael Roth --- target-ppc/kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index c09cc39..29997af 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -558,7 +558,7 @@ int kvm_arch_handle_exit(CPUPPCState *env, struct kvm_run *run) dprintf("handle PAPR hypercall\n"); run->papr_hcall.ret = spapr_hypercall(env, run->papr_hcall.nr, run->papr_hcall.args); - ret = 1; + ret = 0; break; #endif default: -- 1.7.9.5