On 26/03/2015 17:52, Nate Case wrote: > I don't think the "x/70i 0" output reflected where the CPU was actually > executing? Based on the CS:IP of 9020:0058 (0x90258), shouldn't I be > dumping from around 0x90200 instead? gdb gets easily confused here Ah, this was gdb (QEMU has its own monitor and it sums the CS base if you use $pc, but not if you write an absolute address). > 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. Please run "info registers" from QEMU instead, so that it's possible to see the hidden part of the segment registers. Paolo > 0x90266: call 0x9027f > 0x90269: in al,0x64 > 0x9026b: cmp al,0xff > 0x9026d: je 0x9027e > 0x9026f: test al,0x1 > 0x90271: je 0x9027a > 0x90273: call 0x9027f > 0x90276: in al,0x60 > 0x90278: jmp 0x90266 > 0x9027a: test al,0x2 > 0x9027c: jne 0x90266 > 0x9027e: ret > 0x9027f: jmp 0x90281 > 0x90281: ret > 0x90282: add BYTE PTR [bx+si],al > 0x90284: add BYTE PTR [bx+si],al > 0x90286: add BYTE PTR [bx+si],al > 0x90288: add BYTE PTR [bx+si],al > 0x9028a: add BYTE PTR [bx+si],al > 0x9028c: add BYTE PTR [bx+si],al > 0x9028e: add BYTE PTR [bx+si],al > 0x90290: add BYTE PTR [bx+si],al > 0x90292: (bad) > 0x90293: jg 0x90295 > 0x90295: add BYTE PTR [bx+si],al > 0x90297: call 0xffff:0xc0 > 0x9029c: (bad) > 0x9029d: (bad) > > Thanks, > > Nate > -- 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
