Re: WARN_ON in kvm_queue_exception_e triggers

Jan Kiszka
2008-04-29T10:34:37Z

Joerg Roedel wrote:
> On Tue, Apr 29, 2008 at 10:38:41AM +0200, Jan Kiszka wrote:
>> Joerg Roedel wrote:
>>> Hmm, seems we have to check for DF and triple faults in the
>>> kvm_queue_exception functions too. Does the attached patch fix the
>>> problem (patch is against kvm-66).
>> Thanks, it indeed fixes the warnings (*) and makes KVM issue a reset. But
>> then is stumbles and falls probably over some inconsistent system state:
>>
>> exception 13 (43)
>> rax 0000000000000000 rbx 0000000000000000 rcx 0000000000000000 rdx 0000000000000633
>> rsi 0000000000000000 rdi 0000000000000000 rsp 0000000000000000 rbp 0000000000000000
>> r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000
>> r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000
>> rip 000000000000fff0 rflags 00033002
>> cs f000 (000f0000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> es 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
>> tr 0178 (fffbd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
>> ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0)
>> gdt 0/ffff
>> idt 0/ffff
>> cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0
>> code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>
>> Looks like trying to execute the first instruction after reset is
>> already unsuccessful. As the tr selector is non-zero here, I already
>> tried a kvm_arch_reset_cpu-hack along the line that sets
>> KVM_REQ_TRIPLE_FAULT, but without success. Any idea what to check?
>
> Its weird to me what triggers the taskswitch. What guest operating

It is the guest, looking for a soft-restart (after it detected some
other error - now our main problem).

> system are you running and what is the qemu/kvm command line to start
> the guest?

Well, the guest is a proprietary OS of our customer, running in 16-bit
protected mode with a lot of segment shuffling. Due to this and also
some special hardware emulations, the current test case is not portable.
So I'm looking for input on where to dig and what to try.

Note that I ran the very same test with -no-kvm, and here we do not get
those post-reset GPF (provided that some reset-on-triple-fault patch is
applied to avoid the abort(), e.g. [1]).

>
>> Note that this does not happen when I raise a reset via the monitor.
>>
>> BTW, kvm_show_code() does not seem to provide correct informations,
>> even when I add it right before the first kvm_run().
>
> When the guest state is messed up the information may be incorrect.

I don't expect the guest state to be messed up right before the very
first guest code execution (that's where kvm_show_code() also reported
zeros)... :->

>
>> (*) There is just a bit noise left behind in the syslog:
>>
>> kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9
>
> Reason 0x9 is the taskswitch intercept.
>
>> kvm: inject_page_fault: double fault
>
> This is expected from the patch I sent you.

For sure. I would just suggest to rethink if a final version should
still issue such warnings. We basically had the same discussion on
qemu-devel around the reset-on-triple-fault patch (which is
unfortunately still not finalized :-/).

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/24475