> > 0x90249: mov ax,0x1 > > 0x9024c: lmsw ax > > 0x9024f: jmp 0x90251 > > 0x90251: mov ax,0x18 > > 0x90254: mov ds,ax > > 0x90256: mov es,ax > > 0x90258: mov ss,ax <-- the "real" IP > > 0x9025a: mov fs,ax > > 0x9025c: mov gs,ax > > 0x9025e: jmp 0x10:0x10000 > > This makes more sense. The processor is looking at this code at least > until 0x9024c, because of this in the trace: > > qemu-system-x86-3937 [002] 1474032.001887: kvm_exit: reason > CR_ACCESS rip 0x4c > qemu-system-x86-3937 [002] 1474032.001887: kvm_cr: cr_write 0 > = 0x11 > > (bit 4 is always 1 so you see 0x11). > > However, the trace then shows a crash (triple fault) at 0x63, not 0x58.
I was curious about the crash at 0x63 instead of 0x58, and I realized that the first trace I uploaded had some debug code in the memtest86 setup.S which would have moved the instruction addresses around. So the trace addresses wouldn't have matched the assembly dump exactly. I uploaded a cleaner trace here: http://oss.xes-inc.com/xtmp/trace-pcimem-memtest86-stock-reset.dat.gz This was used with the stock memtest86 code and also with "-no-reboot" so you don't see the subsequent boot in the trace. In this trace, at the end the last guest_rip reference I see is 0x58 now: kvm_exit: [FAILED TO PARSE] exit_reason=30 guest_rip=0x69 kvm_pio: pio_read at 0x64 size 1 count 1 kvm_entry: vcpu 0 kvm_exit: [FAILED TO PARSE] exit_reason=28 guest_rip=0x4c kvm_cr: cr_write 0 = 0x11 kvm_mmu_get_page: [FAILED TO PARSE] gfn=0 role=983104 root_count=0 unsync=0 created=0 kvm_entry: vcpu 0 kvm_exit: [FAILED TO PARSE] exit_reason=2 guest_rip=0x58 QEMU register dump after the failure looks the same as my last post: (qemu) info registers EAX=00000018 EBX=00000000 ECX=00002000 EDX=00000092 ESI=00005a00 EDI=00003ff4 EBP=000001d0 ESP=00000800 EIP=00000058 EFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 ffffffff ffffffff 00f0ff00 DPL=3 CS64 [CRA] CS =9020 00090200 ffffffff 00809b00 DPL=0 CS16 [-RA] SS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] DS =0018 ffffffff ffffffff 00f0ff00 DPL=3 CS64 [CRA] FS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] GS =9000 00090000 ffffffff 00809300 DPL=0 DS16 [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 00090282 00000800 IDT= 00000000 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Instruction dump (matches setup.S code from memtest86+): (qemu) x/60i 0x90200 0x0000000000090200: cli 0x0000000000090201: mov $0x80,%al 0x0000000000090203: out %al,$0x70 0x0000000000090205: mov $0x9000,%ax 0x0000000000090208: mov %ax,%ds 0x000000000009020a: mov %ax,%es 0x000000000009020c: mov %ax,%fs 0x000000000009020e: mov %ax,%ss 0x0000000000090210: mov %dx,%sp 0x0000000000090212: push %cs 0x0000000000090213: pop %ds 0x0000000000090214: lidtw 0xa2 0x0000000000090219: lgdtw 0xa8 0x000000000009021e: mov $0x92,%dx 0x0000000000090221: in (%dx),%al 0x0000000000090222: cmp $0xff,%al 0x0000000000090224: je 0x90238 0x0000000000090226: addr32 mov 0x4(%esp),%ah 0x000000000009022b: test %ah,%ah 0x000000000009022d: je 0x90233 0x000000000009022f: or $0x2,%al 0x0000000000090231: jmp 0x90235 0x0000000000090233: and $0xfd,%al 0x0000000000090235: and $0xfe,%al 0x0000000000090237: out %al,(%dx) 0x0000000000090238: call 0x90266 0x000000000009023b: mov $0xd1,%al 0x000000000009023d: out %al,$0x64 0x000000000009023f: call 0x90266 0x0000000000090242: mov $0xdf,%al 0x0000000000090244: out %al,$0x60 0x0000000000090246: call 0x90266 0x0000000000090249: mov $0x1,%ax 0x000000000009024c: lmsw %ax 0x000000000009024f: jmp 0x90251 0x0000000000090251: mov $0x18,%ax 0x0000000000090254: mov %ax,%ds 0x0000000000090256: mov %ax,%es 0x0000000000090258: mov %ax,%ss <- pc 0x000000000009025a: mov %ax,%fs 0x000000000009025c: mov %ax,%gs 0x000000000009025e: ljmpl $0x10,$0x10000 0x0000000000090266: call 0x9027f 0x0000000000090269: in $0x64,%al 0x000000000009026b: cmp $0xff,%al 0x000000000009026d: je 0x9027e 0x000000000009026f: test $0x1,%al 0x0000000000090271: je 0x9027a 0x0000000000090273: call 0x9027f 0x0000000000090276: in $0x60,%al 0x0000000000090278: jmp 0x90266 0x000000000009027a: test $0x2,%al 0x000000000009027c: jne 0x90266 0x000000000009027e: ret 0x000000000009027f: jmp 0x90281 0x0000000000090281: ret 0x0000000000090282: add %al,(%bx,%si) 0x0000000000090284: add %al,(%bx,%si) 0x0000000000090286: add %al,(%bx,%si) 0x0000000000090288: add %al,(%bx,%si) I also switched to using sysfs file "resource2" for now instead of "resource2_wc", but the behavior appears to be the same in both cases. Thanks, Nate -- 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
