On 12/12/2014 22:39, Andy Lutomirski wrote: > KVM internal error. Suberror: 3 > extra data[0]: 80000202 > extra data[1]: 31 > EAX=8be4df61 EBX=8be4df61 ECX=3ff6002c EDX=11d293ca > ESI=3f08e408 EDI=3e82df7c EBP=3e82deb8 ESP=3e82de7c > EIP=3ff51206 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] > CS =0010 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] > SS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] > DS =0018 00000000 ffffffff 00c09300 DPL=0 DS [-WA] > FS =0000 92c2c700 ffffffff 00c00000 > GS =0000 3ec00000 ffffffff 00c00000 > LDT=0000 00000000 ffffffff 00c00000 > TR =0040 3ec11440 00002087 00008b00 DPL=0 TSS32-busy > GDT= 04c43171 00000020 > IDT= ff57a000 00000fff > CR0=00050033 CR2=022e5000 CR3=0009c000 CR4=000407f0 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > EFER=0000000000000801 > Code=0f be 11 29 d0 5b 5d c3 55 89 e5 8b 45 08 5d 8b 50 04 8b 00 <c3> > 55 89 e5 8b 45 0c 8b 55 10 8b 4d 08 89 01 89 51 04 5d c3 55 31 c0 89 > e5 5d c3 55 89 e5 > > I deliberately triggered a guest bug, but I didn't expect this > failure. I think that the issue is that an NMI was delivered using a > bogus IDT, but I think it should have been cleanly promoted to a > double fault and then a triple fault. Is this a KVM bug? Yeah, it should have triggered a triple fault. This looks like a failed vmentry, due to invalid state in the VMCS. It would be great to have a reproducer using kvm-unit-tests, or failing that a reproducer kernel module for the guest. Paolo Paolo -- 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
