On Thu, 2009-10-15 at 02:10 +0900, Avi Kivity wrote: > 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? ffffffff85d85b24 B __bss_stop ffffffff85d86000 B __brk_base ffffffff85d96000 b .brk.dmi_alloc ffffffff85da6000 B __brk_limit ffffffffff600000 T vgettimeofday ffffffffff600100 t vread_tsc ffffffffff600130 t vread_hpet ffffffffff600140 D __vsyscall_gtod_data ffffffffff600400 T vtime -Andrew -- 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
