Show registers and exit on unhandled errors
PATCH 1/1 Show registers and exit on unhandled errors
--- qemu-kvm.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
qemu-kvm.c +2 -0
@@ -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);
Signature · 1 line
1.6.0.4
Quoted 10 lines · Mohammed Gamal
Signed-off-by Mohammed Gamal <[email protected]>--- qemu-kvm.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)qemu-kvm.c +0
-0
qemu-kvm.c int kvm_run(kvm_vcpu_context_t vcpu, void *env) · line 1022
Quoted 8 lines
qemu-kvm.c +2
-0@@ -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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 20 lines · Jan Kiszka
Quoted 11 lines · Mohammed Gamal
Signed-off-by Mohammed Gamal <[email protected]>---
qemu-kvm.c | 2 ++1 files changed, 2 insertions(+), 0 deletions(-)qemu-kvm.c +0
-0@@ -1015,6 +1015,8 @@ int kvm_run(kvm_vcpu_context_t vcpu, void *env) switch (run->exit_reason) {Quoted 7 lines
case
KVM_EXIT_UNKNOWN:
r =handle_unhandled(run->hw.hardware_exit_reason);
+ kvm_show_regs(vcpu);
+ abort();
break;
caseKVM_EXIT_FAIL_ENTRY:
r =handle_unhandled(run->fail_entry.hardware_entry_failure_reason);
Quoted 8 lines
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?
Quoted 29 lines · Mohammed Gamal
Quoted 18 lines · Jan Kiszka
Quoted 17 lines · Mohammed Gamal
Signed-off-by Mohammed Gamal <[email protected]>--- qemu-kvm.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)qemu-kvm.c +2
-0@@ -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 :Quoted 9 lines
qemu-kvm.c int kvm_run(kvm_vcpu_context_t vcpu, void *env) · line 1022
Quoted 1 line
qemu-kvm.c +0
-0r =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
- ...
Quoted 2 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Quoted 5 lines
Quoted 2 lines
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.
handle_unhandled() doesn't get the vcpu passed to it, so it'd be better we keep kvm_show_regs() at the caller.
Quoted 33 lines · Jan Kiszka
Quoted 29 lines · Mohammed Gamal
Quoted 18 lines · Jan Kiszka
Quoted 17 lines · Mohammed Gamal
Signed-off-by Mohammed Gamal <[email protected]>---
qemu-kvm.c | 2 ++1 files changed, 2 insertions(+), 0 deletions(-)qemu-kvm.c +0
-0@@ -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;
caseKVM_EXIT_FAIL_ENTRY:Quoted 9 lines
Quoted 1 line
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
- ...Quoted 2 lines
Good point. But at least we can still show registers, since that also can give some diagnostic information, no?
Quoted 6 lines
No fundamental concerns. Just move the call into
handle_unhandled.And maybe some note like "
kvm_runreturned XX - VM stopped" inkvm_cpu_exec()would clarify the situation a bit more.Jan
That's already the case if we don't exit.
Quoted 10 lines · Mohammed Gamal
Quoted 10 lines
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
- ...
Quoted 3 lines
Good point. But at least we can still show registers, since that also can give some diagnostic information, no?
There's 'info registers' for that.
Signature · 1 line
error compiling committee.c: too many arguments to function