Mohammed Gamal wrote: > Signed-off-by: Mohammed Gamal <[email protected]> > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
