I just tried Richard's fix against HEAD (6a4e17711) and it works for me.
I also like that his fix clearly constrains aflag to the values 1 and 2
for 64bit mode - a concept which matches the intent of the 0x67 prefix.
$ git diff target-i386/translate.c
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 0aeccdb..cb7fe0b 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -4816,6 +4816,8 @@ static target_ulong disas_insn(CPUX86State *env, DisasCont
if (!(prefixes & PREFIX_ADR)) {
aflag = 2;
}
+ /* 0x67 toggles between 64-bit and 32-bit addressing */
+ aflag = (prefixes & PREFIX_ADR ? 1 : 2);
}
#endif
--
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:
In Progress
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
