From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lw9dJ-0003f6-92 for qemu-devel@nongnu.org; Tue, 21 Apr 2009 02:39:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lw9dH-0003ei-Lg for qemu-devel@nongnu.org; Tue, 21 Apr 2009 02:39:04 -0400 Received: from [199.232.76.173] (port=57440 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lw9dH-0003ef-Eu for qemu-devel@nongnu.org; Tue, 21 Apr 2009 02:39:03 -0400 Received: from smtp22.services.sfr.fr ([93.17.128.13]:27467) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lw9dG-0007A9-UF for qemu-devel@nongnu.org; Tue, 21 Apr 2009 02:39:03 -0400 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2201.sfr.fr (SMTP Server) with ESMTP id 845F97000097 for ; Tue, 21 Apr 2009 08:39:01 +0200 (CEST) Received: from [77.207.3.30] (unknown [77.207.3.30]) by msfrf2201.sfr.fr (SMTP Server) with ESMTP id 6E57F7000090 for ; Tue, 21 Apr 2009 08:39:01 +0200 (CEST) Subject: Re: [Qemu-devel] multi-bytes nop and 64bits From: Mark Karpeles In-Reply-To: References: <1240249899.9112.2867.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Tue, 21 Apr 2009 08:38:58 +0200 Message-Id: <1240295938.9112.3529.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, Le mardi 21 avril 2009 =C3=A0 02:10 +0400, malc a =C3=A9crit : > On Mon, 20 Apr 2009, Mark Karpeles wrote: > > As seen by qemu (QEMU PC emulator version 0.10.1): > >=20 > > 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 vie= w. 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