Re: Problem with KVM guest switching to x86 long mode

[Avi Kivity <avi@redhat.com>]

On 04/08/2010 09:59 PM, Pekka Enberg wrote:
>
>>>    2b:*    cb                       lret<-- trapping instruction
>>
>> Post the two u32s at ss:rsp -> ss:rsp+8.  That will tell us where the 
>> guest is trying to return.  Actually, from the dump:
>>
>>  1a:    6a 10                    pushq  $0x10
>>   1c:    8d 85 00 02 00 00        lea    0x200(%rbp),%eax
>>   22:    50                       push   %rax
>>
>> it looks like you're returning to segment 0x10, this should be the 
>> word at ss:rsp+4.  So if you dump the 2 u32s at 
>> gdtr.base+0x10..gdtr.base+0x18 we'll see if there's anything wrong 
>> with the segment descriptor.
>
> Here you go:

I was asking for the wrong things.

>
> penberg@tiger:~/vm$ ./kvm bzImage
> KVM exit reason: 8 ("KVM_EXIT_SHUTDOWN")
> Registers:
>  rip: 00000000001000ed   rsp: 00000000005d54b8 flags: 0000000000010046
>  rax: 0000000080000001   rbx: 0000000001f2c000   rcx: 00000000c0000080
>  rdx: 0000000000000000   rsi: 0000000000013670   rdi: 0000000002408000
>  rbp: 0000000000100000   r8:  0000000000000000   r9:  0000000000000000
>  r10: 0000000000000000   r11: 0000000000000000   r12: 0000000000000000
>  r13: 0000000000000000   r14: 0000000000000000   r15: 0000000000000000
>  cr0: 0000000080000011   cr2: 00000000001000ed   cr3: 0000000002402000

cr2 points at rip.  So it isn't lret not executing correctly, it's the 
cpu not able to fetch lret at all.

The code again:

>    23:	b8 01 00 00 80       	mov    $0x80000001,%eax
>    28:	0f 22 c0             	mov    %rax,%cr0
>    2b:*	cb                   	lret<-- trapping instruction
>    

The instruction at 0x28 is enabling paging, next insn fetch faults, so 
the paging structures must be incorrect.

Questions:
- what is the u64 at cr3? (call it pte4)
- what is the u64 at (pte4 & ~0xfff)?  (call it pte3)
- what is the u64 at (pte3 & ~0xfff)? ("pte2")
- what is the u64 at ((pte2 & ~0xfff) + 2048)? ("pte1")

Note if bit 7 of pte2 is set, then pte1 is unneeded.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.