From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Problem in real mode test harness. Date: Tue, 26 Aug 2008 19:02:17 +0300 Message-ID: <48B42909.1060405@qumranet.com> References: <52d4a3890808260854y23987573m7d0e610e4aa436fe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Mohammed Gamal Return-path: Received: from il.qumranet.com ([212.179.150.194]:48519 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754829AbYHZQCT (ORCPT ); Tue, 26 Aug 2008 12:02:19 -0400 In-Reply-To: <52d4a3890808260854y23987573m7d0e610e4aa436fe@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: Mohammed Gamal wrote: > When trying to run the real mode test harness with > emulate_invalid_guest_state=1. It crashes with a #GP exception, here > is the output: > --- > exception 13 (0) > rax 00000000c03104d2 rbx 0000000000000000 rcx 0000000031664000 rdx > 0000000000001000 > rsi 0000000000000001 rdi 0000000000000000 rsp 0000000000020000 rbp > 0000000000000000 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 0000000000100010 rflags 00010006 > cs 0008 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) > ds 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > es 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > ss 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > fs 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > gs 0010 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > tr 0000 (00000000/0000ffff 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 f0110/17 > idt 0/7ff > cr0 60000011 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > code: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 --> > 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 > 01 01 01 01 01 01 01 > --- > > I wanted to take a look at the emulated instruction, so I added some > logging to the kvm-intel module, here is the dmesg output > [11343.221039] emulation failed (emulation success) rip f00de 66 b8 10 00 > [11343.221039] emulation failed (emulation success) rip f00e2 8e d8 8e c0 > [11343.222936] emulation failed (emulation success) rip f00e4 8e c0 8e e0 > [11343.222936] emulation failed (emulation success) rip f00e6 8e e0 8e e8 > [11343.222936] emulation failed (emulation success) rip f00e8 8e e8 8e d0 > [11343.222936] emulation failed (emulation success) rip f00ea 8e d0 bc 00 > [11343.222936] emulation failed (emulation success) rip f00ec bc 00 00 02 > [11343.222936] emulation failed (emulation success) rip f00f1 ea 00 00 10 > [11343.222936] emulation failed (emulation success) rip 100000 b8 d2 04 31 > [11343.222936] emulation failed (emulation success) rip 100005 8e d8 8e c0 > [11343.222936] emulation failed (emulation success) rip 100007 8e c0 8e d0 > [11343.222936] emulation failed (emulation success) rip 100009 8e d0 b9 00 > [11343.222936] emulation failed (emulation success) rip 10000b b9 00 40 66 > [11343.222936] emulation failed (emulation success) rip 100010 f6 66 89 f7 > [11343.222936] emulation failed (emulation failure) rip 100010 f6 66 89 f7 > --- > (Note: I am using kvm_report_emulation_failure() to report all > emulated instructions even those which succeeded) > > Looking at the instruction sequence, it corresponds to the following > sequence in realmode.c > asm( > ".data \n\t" > ". = . + 4096 \n\t" > "stacktop: \n\t" > ".text \n\t" > "init: \n\t" > "xor %ax, %ax \n\t" > "mov %ax, %ds \n\t" > "mov %ax, %es \n\t" > "mov %ax, %ss \n\t" > "mov $0x4000, %cx \n\t" > "xor %esi, %esi \n\t" > > we fail at the xor %esi, %esi instruction. I thought at first it > might be an emulation problem with xor, so I changed the instruction > to mov $0, %esi and we still fail. Another strange thing is that the > emulator reads the opcode for xor and mov instructions, but fails when > reading the operands. I looked at the emulator code but it looks OK, > so why is the exception generated? It looks like we actually fail at the mov insn. The insn is (rip 10000b): b9 00 40 mov $0x4000,%cx three bytes long, so next rip should be 10000e, but it reads 5 bytes and ends up in 100010. I don't understand what the code is doing in that address range anyway. Looks like it accidentally switched to 32-bit protected mode somehow. Are you running realmode.c as is, or patched? -- error compiling committee.c: too many arguments to function