Ok, somehow the firewall was messed up - it works now. :/
4a6fd938f5457ee161d2acbd9364608a2a68b7a1 is the first bad commit commit 4a6fd938f5457ee161d2acbd9364608a2a68b7a1 Author: Richard Henderson <r...@twiddle.net> Date: Thu Jan 10 13:29:23 2013 -0800 target-i386: Tidy prefix parsing Avoid duplicating switch statement between 32 and 64-bit modes. Signed-off-by: Richard Henderson <r...@twiddle.net> :040000 040000 19911356bcd4fe71bfc36485c066368a439edd2d ca7c74f1404cb025f3dbb7a77966a790ae7e890f M target-i386 The previous commit (988c3eb0d) works fine. -- 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: New 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