[Bug 1703147] Re: Xfer:features:read truncating xml sent to gdb frontends
Problematic code now around lines 2221 (in handle_query_xfer_features) ... lol I'm the only one impacted ... all the large register set cpus can be affected. ** Changed in: qemu Status: Expired => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1703147 Title: Xfer:features:read truncating xml sent to gdb frontends Status in QEMU: New Bug description: Around line 1326 in gdbstub.c: if (len > (MAX_PACKET_LENGTH - 5) / 2) len = (MAX_PACKET_LENGTH - 5) / 2; is truncating processor reg description xml files longer than 2045 bytes. Deleting these lines works for my immediate need, but they seem to be trying to fix some buffer overrun condition so I won't offer a patch until we understand their purpose. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1703147/+subscriptions
[Qemu-devel] [Bug 1686170] Re: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options
Apparently none of the 32bit x86 modes are supported in 2.9 version of qemu-system-x86_64. I realize the desire to simplify the code, and separate i386 from x86_64, but x86_64 really does need to support all the modes in which the processor can operate. True that for major operating systems the processor is only briefly in any 32bit mode, but for boot ROM and boot loader work, and non-mainstream kernels we still very much need 32bit support *in* the x86_64 qemu. Previously the 'g' RDP query (gdbstub.c:1056) would send a different length of reg data depending on in which mode the cpu was currently operating. Although maybe not a great ABI, it was sufficient to tell exactly when the cpu changed states and front end debuggers need to know this. Unfortunately the much more portable new .xml register definition scheme needs to be changed to properly support multiple register sets (with different names sizes etc.), but x86 is not the only processor to have multiple personalities. An example implementation for x86 could be that the "top" level xml file i386-64bit.xml describes all the different possible modes (something like): all of which are loaded when the frontend starts. The 'g' RDP response should then start with one of the feature names (or an abbreviated unique id). In fact, ring0 vs ring1-3 should likely also have different xml files as the crX config registers need to be sent when in ring 0 as well. Commit that made this change: https://github.com/qemu/qemu/commit/00fcd100c3f47445f6a59d39e11601460880cfe4 #diff-b8f1948d6e81e8ccdbe828ba7973c483 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1686170 Title: qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options Status in QEMU: New Bug description: OS: Void Linux x86_64 (glibc) QEMU version: 2.9.0 GDB version: 7.12.1 Problem description: After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'. To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult. Steps to reproduce: - Run QEMU - In another terminal, run GDB - In GDB, connect to QEMU - In GDB, disassemble some Real mode machine code. Expected results (from QEMU version 2.8.1): [terminal #1] $ qemu-system-x86_64 -S -s [terminal #2] (gdb) set architecture i8086 warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i8086 settings. The target architecture is assumed to be i8086 (gdb) target remote :1234 Remote debugging using :1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0xfff0 in ?? () (gdb) x/i $cs*16+$eip 0x0: ljmp $0xf000,$0xe05b Actual results: [terminal #1] $ qemu-system-x86_64 -S -s [terminal #2] $ gdb -q (gdb) set architecture i8086 warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration of GDB. Attempting to continue with the default i8086 settings. The target architecture is assumed to be i8086 (gdb) target remote :1234 Remote debugging using :1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. Remote 'g' packet reply is too long: [..snip..] Workarounds tried: - Try different architecures (gdb) set architecture i386:intel The target architecture is assumed to be i386:intel (gdb) target remote :1234 Remote debugging using :1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. Remote 'g' packet reply is too long: [..snip..] (gdb) set architecture i386:x86-64 The target architecture is assumed to be i386:x86-64 (gdb) target remote :1234 Remote debugging using :1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0xfff0 in ?? () The last try finally allowed me to connect to QEMU, but as can be expected from using an incorrect architecture setting, disassembly output is complete gibberish: (gdb) x/10i $cs*16+$rip
[Qemu-devel] [Bug 1703147] [NEW] Xfer:features:read truncating xml sent to gdb frontends
Public bug reported: Around line 1326 in gdbstub.c: if (len > (MAX_PACKET_LENGTH - 5) / 2) len = (MAX_PACKET_LENGTH - 5) / 2; is truncating processor reg description xml files longer than 2045 bytes. Deleting these lines works for my immediate need, but they seem to be trying to fix some buffer overrun condition so I won't offer a patch until we understand their purpose. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1703147 Title: Xfer:features:read truncating xml sent to gdb frontends Status in QEMU: New Bug description: Around line 1326 in gdbstub.c: if (len > (MAX_PACKET_LENGTH - 5) / 2) len = (MAX_PACKET_LENGTH - 5) / 2; is truncating processor reg description xml files longer than 2045 bytes. Deleting these lines works for my immediate need, but they seem to be trying to fix some buffer overrun condition so I won't offer a patch until we understand their purpose. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1703147/+subscriptions
Re: [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
Sigh. 3 years ago I could test this - today? Not possible. I'm sorry I can't confirm. :/ -- 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 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ... 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
[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
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
0x0001
RAX=3e084da8 RBX=3e084868 RCX=
RDX=3e084f00
RSI=0001 RDI=3e085000 RBP=3e084708
RSP=3fac8510
R8 = R9 =3e14c3e3 R10=0033
R11=00d3
R12=3e0848a0 R13= R14=
R15=
RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0008 00cf9300 DPL=0 DS [-WA]
CS =0028 00af9b00 DPL=0 CS64 [-RA]
SS =0008 00cf9300 DPL=0 DS [-WA]
DS =0008 00cf9300 DPL=0 DS [-WA]
FS =0008 00cf9300 DPL=0 DS [-WA]
GS =0008 00cf9300 DPL=0 DS [-WA]
LDT= 8200 DPL=0 LDT
TR = 8b00 DPL=0 TSS64-busy
GDT= 3fa50e98 003f
IDT= 3f9d6e20 0fff
CR0=8033 CR2= CR3=3fa67000 CR4=0668
...
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
[Qemu-devel] [Bug 1180970] *** affects all x86_64 soft emulation
qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92 Want to bring a little attention to this bug - the break is in target-i386/translate.c which affects all x86_64 soft emulation in a fairly subtle way (ie. users will report a wide variety of problems none of which seem to be related). I can't find a way to elevate bug importance in launchpad. 4a6fd938f5457ee161d2acbd9364608a2a68b7a1 is the offending commit. There have been numerous changes after this commit over top of the change that broke emulation, so backing out this commit is not trivial. I can reproduce the problem that is the subject of bug 1180970 for testing easily.
Re: [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
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 :04 04 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 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ... 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
Re: [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
Is there something special about this git repo? I can pull other git repos through my firewall with no problems, but this one fails (always at the same place) with: $ git clone http://git.qemu.org/git/qemu.git Cloning into 'qemu'... ### takes 1 or 2 mins - can see a lot of git objects succeed, then: error: The requested URL returned error: 407 authenticationrequired (curl_result = 22, http_code = 407, sha1 = cad2b59c198340a636c5e015fb90e0326a1d3dd7) error: Unable to find cad2b59c198340a636c5e015fb90e0326a1d3dd7 under http://git.qemu.org/git/qemu.git Cannot obtain needed commit cad2b59c198340a636c5e015fb90e0326a1d3dd7 while processing commit b174de51ae397549f58b1b76efa9026b213a1efd. error: Fetch failed. -- 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 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ... 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
[Qemu-devel] upgrade from 1.4.0 to 1.4.91 - qemu: fatal: Trying to execute code outside RAM or ROM
I noticed there havent been any fatal: Trying to execute code outside RAM or ROM issues since 2011. qemu 1.4.0 ran this identical uEFI environment with no trouble. Is this failure in 1.5.0-rc1 interesting? The qemu guest console window appears, the OVMF splash screen is displayed, and then it all dies with a register dump: /usr/local/bin/qemu-system-x86_64 -m 1024 -bios OVMF.fd many_more_args QEMU 1.4.91 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ...
Re: [Qemu-devel] upgrade from 1.4.0 to 1.4.91 - qemu: fatal: Trying to execute code outside RAM or ROM
same thing with 1.4.92 (rc2): QEMU 1.4.92 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 On Thu, May 16, 2013 at 11:59 AM, Duane Voth dua...@gmail.com wrote: I noticed there havent been any fatal: Trying to execute code outside RAM or ROM issues since 2011. qemu 1.4.0 ran this identical uEFI environment with no trouble. Is this failure in 1.5.0-rc1 interesting? The qemu guest console window appears, the OVMF splash screen is displayed, and then it all dies with a register dump: /usr/local/bin/qemu-system-x86_64 -m 1024 -bios OVMF.fd many_more_args QEMU 1.4.91 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ... -- http://www.goldmoney.com/index.html?gmrefcode=dvau7 Obsolete [ruling] classes do not voluntarily abandon the stage of history. - Joseph Stalin Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. - Albert Einstein
[Qemu-devel] [Bug 1180970] [NEW] qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92
Public bug reported: 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 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ... 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? ** Affects: qemu Importance: Undecided Status: New -- 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 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ... 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
[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
Attching the bios I'm using (you may be able to reproduce the problem with this file alone). ** Attachment added: Tianocore EDK2 OVMF bios image https://bugs.launchpad.net/qemu/+bug/1180970/+attachment/3678650/+files/OVMF.fd -- 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 0x0001 RAX=3e084da8 RBX=3e084868 RCX= RDX=3e084f00 RSI=0001 RDI=3e085000 RBP=3e084708 RSP=3fac8510 R8 = R9 =3e14c3e3 R10=0033 R11=00d3 R12=3e0848a0 R13= R14= R15= RIP=ffe4 RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0008 00cf9300 DPL=0 DS [-WA] CS =0028 00af9b00 DPL=0 CS64 [-RA] SS =0008 00cf9300 DPL=0 DS [-WA] DS =0008 00cf9300 DPL=0 DS [-WA] FS =0008 00cf9300 DPL=0 DS [-WA] GS =0008 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 3fa50e98 003f IDT= 3f9d6e20 0fff CR0=8033 CR2= CR3=3fa67000 CR4=0668 ... 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
Re: [Qemu-devel] [Bug 1180970] [NEW] qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92
Ha, I thought kvm was on by default. Apparently not, qemu -enable-kvm avoids this issue. Yes, 0x0001 with RIP=ffe4 is quite suspicious, especially after the splash screen has been displayed. Off in the weeds comes to mind - so I'm guessing corrupted or incorrectly mapped guest memory? The git tree is where? (I just grabbed the tarball)
