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.
--
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
