[Qemu-devel] [Bug 1180970] Re: qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92

From: "T. Huth" <1180970@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1180970] Re: qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92
Date: Wed, 28 Sep 2016 14:28:39 -0000	[thread overview]
Message-ID: <20160928142839.21379.84015.malone@soybean.canonical.com> (raw)
In-Reply-To: 20130516195843.983.69688.malonedeb@soybean.canonical.com

I think this has likely been fixed by this commit here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=dec3fc9657e0682637de4d
... so setting the status to "Fix Released" now. If the problem still persists, please feel free to open this ticket again.

** Changed in: qemu
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1180970

Title:
  qemu: fatal: Trying to execute code outside RAM or ROM; worked in
  1.4.0, fails in 1.4.92

Status in QEMU:
  Fix Released

Bug description:
  I'm using qemu to run and debug the EDK2 uEFI environment. OVMF is
  being built out of the EDK2 tree I've checked out (r14367).
  (Reproducing all this could be tedious so I am available for
  debugging/testing.)

  qemu 1.4.0 was able to execute this guest environment with no trouble,
  qemu 1.4.92 however issues an error message and aborts.  The command
  line I use to start qemu is:

  $ /usr/local/bin/qemu-system-x86_64 -m 1024 -bios OVMF.fd -monitor
  stdio

  1.4.92 gives the following register dump:

  QEMU 1.4.92 monitor - type 'help' for more information
  (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000100000000

  RAX=000000003e084da8 RBX=000000003e084868 RCX=0000000000000000 RDX=000000003e084f00
  RSI=0000000000000001 RDI=000000003e085000 RBP=000000003e084708 RSP=000000003fac8510
  R8 =0000000000000000 R9 =000000003e14c3e3 R10=0000000000000033 R11=00000000000000d3
  R12=000000003e0848a0 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
  RIP=00000000ffffffe4 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
  ES =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
  CS =0028 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA]
  SS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
  DS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
  FS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
  GS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
  LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
  TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
  GDT=     000000003fa50e98 0000003f
  IDT=     000000003f9d6e20 00000fff
  CR0=80000033 CR2=0000000000000000 CR3=000000003fa67000 CR4=00000668
  ...

  Questions:
  1) Is this problem relevant?  (is full backward compatability to be supported?)
  2) Are there new guest execution controls in 1.4.9x that might cause this?
  3) If #2, can they be disabled by a qemu command line switch?
  4) If not #2, in what qemu source file specifically can I find the logic causing the abort? (help me help you :)
  5) If guest memory is corrupted or improperly mapped, how can I keep qemu alive to examime/dump guest memory?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1180970/+subscriptions