qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Mark Karpeles <mark@hell.ne.jp>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] multi-bytes nop and 64bits
Date: Tue, 21 Apr 2009 08:38:58 +0200	[thread overview]
Message-ID: <1240295938.9112.3529.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 had a look at qemu's decompiler (an old version of i386-dec.c from
gdb), and "fixed" it to support nopl correctly (and at least avoid
weird crashes).

Patch:
http://ookoo.org/svn/snip/qemu-0.10.1-nopl-fix.patch

Anyway thanks for the tip, you just saved me more days of head
scratching.

Mark

  parent reply	other threads:[~2009-04-21  6:39 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
2009-04-21  6:38   ` Mark Karpeles [this message]
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=1240295938.9112.3529.camel@localhost \
    --to=mark@hell.ne.jp \
    --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).