On 10/13/2009 11:04 PM, Andrew Theurer wrote:
quoted text
>
>> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html