On 10/13/2009 11:04 PM, Andrew Theurer wrote:
Look at the address where vmx_vcpu_run starts, add 0x26d, and show the
surrounding code.
Thinking about it, it probably _is_ what you showed, due to module page
alignment. But please verify this; I can't reconcile the fault address
(ffffffff9fe9a2b) with %rsp at the time of the fault.
Here is the start of the function:
0000000000003884<vmx_vcpu_run>:
3884: 55 push %rbp
3885: 48 89 e5 mov %rsp,%rbp
and 0x26d later is 0x3af1:
3ad2: 4c 8b b1 88 01 00 00 mov 0x188(%rcx),%r14
3ad9: 4c 8b b9 90 01 00 00 mov 0x190(%rcx),%r15
3ae0: 48 8b 89 20 01 00 00 mov 0x120(%rcx),%rcx
3ae7: 75 05 jne 3aee<vmx_vcpu_run+0x26a>
3ae9: 0f 01 c2 vmlaunch
3aec: eb 03 jmp 3af1<vmx_vcpu_run+0x26d>
3aee: 0f 01 c3 vmresume
3af1: 48 87 0c 24 xchg %rcx,(%rsp)
3af5: 48 89 81 18 01 00 00 mov %rax,0x118(%rcx)
3afc: 48 89 99 30 01 00 00 mov %rbx,0x130(%rcx)
3b03: ff 34 24 pushq (%rsp)
3b06: 8f 81 20 01 00 00 popq 0x120(%rcx)
Ok. So it faults on the xchg instruction, rsp is ffff8806369ffc80 but
the fault address is ffffffff9fe9a2b4. So it looks like the IDT is
corrupted.
Can you check what's around ffffffff9fe9a2b4 in System.map?
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
