Mohammed Gamal wrote:
> On Mon, Sep 21, 2009 at 1:29 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
>> 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
>> - ...
>>
>
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
