| Message ID | 1253531881-3847-1-git-send-email-m.gamal005@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Mohammed Gamal wrote: > Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> > --- > 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
On Mon, Sep 21, 2009 at 1:29 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: > Mohammed Gamal wrote: >> Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> >> --- >> Â 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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mohammed Gamal wrote: > On Mon, Sep 21, 2009 at 1:29 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: >> Mohammed Gamal wrote: >>> Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> >>> --- >>> 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
On Mon, Sep 21, 2009 at 1:42 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: > Mohammed Gamal wrote: >> On Mon, Sep 21, 2009 at 1:29 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: >>> Mohammed Gamal wrote: >>>> Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> >>>> --- >>>> Â 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/21/2009 02:31 PM, Mohammed Gamal wrote: > >> 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? > There's 'info registers' for that.
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);
Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> --- qemu-kvm.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)