Mohammed Gamal wrote:
> Signed-off-by: Mohammed Gamal <m.gamal005@xxxxxxxxx>
> ---
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
