From: "M. Karpelès" <karpeles@ookoo.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] multi-bytes nop and 64bits
Date: Tue, 21 Apr 2009 07:50:49 +0200 [thread overview]
Message-ID: <1240293049.9112.3527.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0904210208320.2237@linmac.oyster.ru>
Hi,
Le mardi 21 avril 2009 à 02:10 +0400, malc a écrit :
> On Mon, 20 Apr 2009, Mark Karpeles wrote:
> > As seen by qemu (QEMU PC emulator version 0.10.1):
> >
> > 0x0000000000201000: (bad)
> > 0x0000000000201002: add %bpl,%cl
> > 0x0000000000201005: sub %edx,0x0(%rcx)
> > 0x0000000000201008: add %al,(%rax)
> > 0x000000000020100a: add %al,(%rax)
> > (The code after this line is not meant to be executed, it's read-only
> > data, and so the system will crash)
> The disassembler is disconnected from the main translation engine, so
> what you see (produced by the older version of i386 disassmbler from
> GNU binutils) might not be what QEMU actually translates/executes. To
> be sure use gdbstub and recent GDB to see, hopefully, more coherent view.
Oh my... I checked more and tried running this without the qemu debug
mode "in_asm", and it's working indeed.
So, in_asm will decompile memory until it reaches a "stop" operation
(ret, %cr3 changed, etc), however if it doesn't reach such an operation
it will continue reading memory.
I wasn't expecting this bug because the fact it was continuing to read
memory caused a page-fault which was catched by the kernel I'm writing.
I never though the debugger could trigger stuff like OS pagefaults (and
of course it was happening with %rip exactly pointing to a long nop,
that's why I wasn't understanding the origin of the page fault).
Maybe this could be added to some documentation: "If guest OS crashes
because of a page fault on a long nop operation, try disabling in_asm
debugging mode".
Or maybe this debugging mode could be fixed to handle long nops? This
debugging mode is really helpful to understand what happened during a
crash, and for people writing their own kernel (like me) it's a life
savior.
I'm not sure how the decompiler works in qemu, but I'll have a look and
see if anything can be done to at least prevent it throwing pagefaults
on bogus addresses when a long nop happens.
Anyway thanks for the tip, you just saved me more days of head
scratching.
Mark
next prev parent reply other threads:[~2009-04-21 5:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-20 17:51 [Qemu-devel] multi-bytes nop and 64bits Mark Karpeles
2009-04-20 22:10 ` malc
2009-04-21 5:50 ` M. Karpelès [this message]
2009-04-21 6:38 ` Mark Karpeles
2009-04-21 17:20 ` malc
2009-04-21 17:39 ` [Qemu-devel] [PATCH] " Mark Karpeles
2009-04-21 18:11 ` Avi Kivity
2009-04-21 22:30 ` malc
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=1240293049.9112.3527.camel@localhost \
--to=karpeles@ookoo.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).