From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] Show registers and exit on unhandled errors Date: Mon, 21 Sep 2009 13:42:46 +0200 Message-ID: <4AB766B6.2020709@siemens.com> References: <1253531881-3847-1-git-send-email-m.gamal005@gmail.com> <4AB763B4.9060603@siemens.com> <52d4a3890909210431j3a1f9f7fpdec49963bfe3ed41@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "avi@redhat.com" , "mtosatti@redhat.com" , "kvm@vger.kernel.org" To: Mohammed Gamal Return-path: Received: from david.siemens.de ([192.35.17.14]:22667 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751401AbZIULm6 (ORCPT ); Mon, 21 Sep 2009 07:42:58 -0400 In-Reply-To: <52d4a3890909210431j3a1f9f7fpdec49963bfe3ed41@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: Mohammed Gamal wrote: > On Mon, Sep 21, 2009 at 1:29 PM, Jan Kiszka wrote: >> Mohammed Gamal wrote: >>> Signed-off-by: Mohammed Gamal >>> --- >>> qemu-kvm.c | 2 ++ >>> 1 files changed, 2 insertions(+), 0 deletions(-) >>> >>> diff --git a/qemu-kvm.c b/qemu-kvm.c >>> index 0afdb56..c22c28a 100644 >>> --- a/qemu-kvm.c >>> +++ b/qemu-kvm.c >>> @@ -1015,6 +1015,8 @@ int kvm_run(kvm_vcpu_context_t vcpu, void *env) >>> switch (run->exit_reason) { >>> case KVM_EXIT_UNKNOWN: >>> r = handle_unhandled(run->hw.hardware_exit_reason); >>> + kvm_show_regs(vcpu); >>> + abort(); >>> break; >>> case KVM_EXIT_FAIL_ENTRY: >>> r = handle_unhandled(run->fail_entry.hardware_entry_failure_reason); >> Don't we currently suspend the VM on unknown exits? This is more useful >> than aborting as it allows to >> - disassemble the problematic code >> - poke around in the RAM >> - look at other VCPUs >> - attach a debugger to qemu >> - ... >> > > Good point. But at least we can still show registers, since that also > can give some diagnostic information, no? No fundamental concerns. Just move the call into handle_unhandled. And maybe some note like "kvm_run returned XX - VM stopped" in kvm_cpu_exec() would clarify the situation a bit more. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux