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:29:56 +0200 Message-ID: <4AB763B4.9060603@siemens.com> References: <1253531881-3847-1-git-send-email-m.gamal005@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org To: Mohammed Gamal Return-path: Received: from thoth.sbs.de ([192.35.17.2]:18586 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754475AbZIULaI (ORCPT ); Mon, 21 Sep 2009 07:30:08 -0400 In-Reply-To: <1253531881-3847-1-git-send-email-m.gamal005@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 - ... Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux