Re: Problem in real mode test harness.

[Avi Kivity <avi@qumranet.com>]

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