On Mon, Sep 21, 2009 at 1:42 PM, Jan Kiszka <[email protected]> wrote: > 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
That's already the case if we don't exit. -- 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
