on 17/09/2013 21:49 Gleb Natapov said the following: > http://www.linux-kvm.org/page/Tracing
Gleb, thank you very much! Here's an interesting snippet from the trace: qemu-system-x86-4639 [003] 263925.182731: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182733: kvm_exit: reason IO_INSTRUCTION rip 0x89b1 info 3f60000 0 qemu-system-x86-4639 [003] 263925.182733: kvm_pio: pio_write at 0x3f6 size 1 count 1 qemu-system-x86-4639 [003] 263925.182734: kvm_userspace_exit: reason KVM_EXIT_IO (2) qemu-system-x86-4639 [003] 263925.182736: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182738: kvm_exit: reason EXCEPTION_NMI rip 0x934e info 0 80000b0d qemu-system-x86-4639 [003] 263925.182739: kvm_emulate_insn: 0:934e:0f 01 1e d6 95 (real) qemu-system-x86-4639 [003] 263925.182741: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182742: kvm_exit: reason EXCEPTION_NMI rip 0x9353 info 0 80000b0d qemu-system-x86-4639 [003] 263925.182743: kvm_emulate_insn: 0:9353:0f 01 16 d0 95 (real) qemu-system-x86-4639 [003] 263925.182745: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182746: kvm_exit: reason EXCEPTION_NMI rip 0x9358 info 0 80000b0d qemu-system-x86-4639 [003] 263925.182747: kvm_emulate_insn: 0:9358:0f 20 c0 (real) qemu-system-x86-4639 [003] 263925.182748: kvm_entry: vcpu 0 qemu-system-x86-4639 [003] 263925.182749: kvm_exit: reason EXCEPTION_NMI rip 0x935c info 0 80000b0d qemu-system-x86-4639 [003] 263925.182750: kvm_emulate_insn: 0:935c:0f 22 c0 (real) qemu-system-x86-4639 [003] 263925.182752: kvm_entry: vcpu 0 CPU:3 [2995 EVENTS DROPPED] qemu-system-x86-4639 [003] 263925.188830: kvm_emulate_insn: 0:9315: (real) qemu-system-x86-4639 [003] 263925.188831: kvm_emulate_insn: 0:9315: (real) qemu-system-x86-4639 [003] 263925.188831: kvm_emulate_insn: 0:9315: (real) ... ad infinitum I believe that the following log from unaccelerated qemu corresponds to the last few instructions: 0x0000000000009346: cli 0x0000000000009347: std 0x0000000000009348: xor %ax,%ax 0x000000000000934a: mov %ax,%ds 0x000000000000934c: mov %ax,%es 0x000000000000934e: lidtw -0x6a2a 0x0000000000009353: lgdtw -0x6a30 0x0000000000009358: mov %cr0,%eax 0x000000000000935b: inc %ax 0x000000000000935c: mov %eax,%cr0 ---------------- IN: 0x000000000000935f: ljmp $0x8,$0x9364 That is, 0x935c seems to be the last meaningful ip and the instruction seems to be enabling protected mode. Not sure how the code ends up at 0x9315 after that. And here is original assembly code: rret_tramp: movw $MEM_ESPR-0x08,%sp # Reset stack pointer pushal # Save gp regs pushl %gs # Save pushl %fs # seg pushl %ds # regs pushl %es pushfl # Save %eflags cli # Disable interrupts std # String ops dec xorw %ax,%ax # Reset seg movw %ax,%ds # regs movw %ax,%es # (%ss is already 0) lidt idtdesc # Set IDT lgdt gdtdesc # Set GDT mov %cr0,%eax # Switch to protected inc %ax # mode mov %eax,%cr0 # ljmp $SEL_SCODE,$rret_tramp.1 # To 32-bit code .code32 rret_tramp.1: xorl %ecx,%ecx # Zero movb $SEL_SDATA,%cl # Setup movw %cx,%ss # 32-bit movw %cx,%ds # seg movw %cx,%es # regs movl MEM_ESPR-0x04,%esp # Switch to kernel stack leal 0x44(%esp,1),%esi # Base of frame andb $~0x2,tss_desc+0x5 # Clear TSS busy movb $SEL_TSS,%cl # Set task ltr %cx # register I can provide full logs, etc. Please let me know what else I could do. Thanks! -- Andriy Gapon