From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Guest memory backed by PCI BAR (x86) Date: Thu, 26 Mar 2015 18:04:31 +0100 Message-ID: <55143C1F.8030402@redhat.com> References: <1790936111.88330.1427298998015.JavaMail.zimbra@xes-inc.com> <55141183.9000304@redhat.com> <1757049852.48328.1427385718889.JavaMail.zimbra@xes-inc.com> <55142EBF.8030600@redhat.com> <57551226.56219.1427387686368.JavaMail.zimbra@xes-inc.com> <55143676.1040709@redhat.com> <1708987913.60506.1427388763363.JavaMail.zimbra@xes-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: kvm@vger.kernel.org To: Nate Case Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57647 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751278AbbCZREi (ORCPT ); Thu, 26 Mar 2015 13:04:38 -0400 In-Reply-To: <1708987913.60506.1427388763363.JavaMail.zimbra@xes-inc.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >