From: Paolo Bonzini <pbonzini@redhat.com>
To: Nate Case <ncase@xes-inc.com>
Cc: kvm@vger.kernel.org
Subject: Re: Guest memory backed by PCI BAR (x86)
Date: Thu, 26 Mar 2015 18:04:31 +0100 [thread overview]
Message-ID: <55143C1F.8030402@redhat.com> (raw)
In-Reply-To: <1708987913.60506.1427388763363.JavaMail.zimbra@xes-inc.com>
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
>
next prev parent reply other threads:[~2015-03-26 17:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 15:56 Guest memory backed by PCI BAR (x86) Nate Case
2015-03-26 14:02 ` Paolo Bonzini
2015-03-26 16:01 ` Nate Case
2015-03-26 16:07 ` Paolo Bonzini
2015-03-26 16:34 ` Nate Case
2015-03-26 16:40 ` Paolo Bonzini
2015-03-26 16:52 ` Nate Case
2015-03-26 17:04 ` Paolo Bonzini [this message]
2015-03-26 17:14 ` Nate Case
2015-03-27 15:27 ` Nate Case
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55143C1F.8030402@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=ncase@xes-inc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.