Mohammed Gamal wrote: > On Mon, Sep 21, 2009 at 1:29 PM, Jan Kiszka <[email protected]> wrote: >> 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 >> - ... >> > > 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 -- 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
