Re: WARN_ON in kvm_queue_exception_e triggers

Joerg Roedel
2008-04-29T10:01:09Z

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
system are you running and what is the qemu/kvm command line to start
the guest?

> 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.

> (*) 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.

Joerg

--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy