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:08:56 +0300 Message-ID: <48B42A98.5000501@qumranet.com> References: <52d4a3890808260854y23987573m7d0e610e4aa436fe@mail.gmail.com> <48B42909.1060405@qumranet.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]:49319 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757210AbYHZQI6 (ORCPT ); Tue, 26 Aug 2008 12:08:58 -0400 In-Reply-To: <48B42909.1060405@qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > 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? > Oh, you're running it with bootstrap.flat, are you? that enters 32-bit protected mode, while this code expects to run from real mode context. Use user/kvmctl user/test/x86/realmode.flat -- error compiling committee.c: too many arguments to function