* [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
2013-05-16 19:58 [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 Duane Voth
@ 2013-05-16 20:01 ` Duane Voth
2013-05-16 21:46 ` [Qemu-devel] [Bug 1180970] [NEW] " Laszlo Ersek
` (6 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Duane Voth @ 2013-05-16 20:01 UTC (permalink / raw)
To: qemu-devel
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 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
^ permalink raw reply [flat|nested] 15+ messages in thread* 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
2013-05-16 19:58 [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 Duane Voth
2013-05-16 20:01 ` [Qemu-devel] [Bug 1180970] " Duane Voth
@ 2013-05-16 21:46 ` Laszlo Ersek
2013-05-16 22:32 ` Duane Voth
2013-05-17 10:20 ` Paolo Bonzini
2013-05-17 15:35 ` [Qemu-devel] [Bug 1180970] " Launchpad Bug Tracker
` (5 subsequent siblings)
7 siblings, 2 replies; 15+ messages in thread
From: Laszlo Ersek @ 2013-05-16 21:46 UTC (permalink / raw)
To: Bug 1180970; +Cc: Duane Voth, qemu-devel
On 05/16/13 21:58, Duane Voth wrote:> 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 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?
I reckon you don't see this with KVM enabled. (Because I don't see it
with KVM enabled, with my own OVMF builds anyway :), plus the "Trying to
execute code outside RAM or ROM" message comes from code that strikes me
as part of TCG.)
It surprises me that RIP=00000000ffffffe4 whereas get_page_addr_code()
[cputlb.c] logs "at 0x0000000100000000".
The RIP seems to be in OVMF init code.
0x0000000100000000 is 4G exactly and looks suspicious.
Can you try bisecting TCG between 1.4.0 and current master?
git log --oneline --reverse v1.4.0.. -- tcg \
| egrep -v 'tcg[-/](arm|ppc|sparc|s390|mips)'
0b0d332 TCG: Final globals clean-up
5e5f07e TCG: Move translation block variables to new context inside tcg_ctx: tb_ctx
24537a0 qemu-log: Rename the public-facing cpu_set_log function to qemu_set_log
e6a7273 tcg: Make 32-bit multiword operations optional for 64-bit hosts
bbc863b tcg-i386: Always implement 32-bit multiword ops
d7156f7 tcg: Add 64-bit multiword arithmetic operations
4d3203f tcg: Add signed multiword multiplication operations
3c51a98 tcg: Implement a 64-bit to 32-bit extraction helper
696a8be tcg: Implement multiword multiply helpers
f6953a7 tcg: Implement multiword addition helpers
624988a tcg-i386: Implement multiword arithmetic ops
f402f38 tcg: Implement muls2 with mulu2
f1fae40 tcg: Apply life analysis to 64-bit multiword arithmetic ops
989b697 qemu-log: default to stderr for logging output
0980011 tcg: Document tcg_qemu_tb_exec() and provide constants for low bit uses
378df4b Handle CPU interrupts by inline checking of a flag
294e466 Use proper term in TCG README
2d49754 tcg-optimize: Fold sub r,0,x to neg r,x
03fc054 tci: Use 32-bit signed offsets to loads/stores
4699ca6 tci: Delete unused tb_ret_addr
ee79c35 tci: Make tcg temporaries local to tcg_qemu_tb_exec
0a9c234 Merge branch 'tci' of git://qemu.weilnetz.de/qemu
ed60512 tcg: fix deposit_i64 op on 32-bit targets
d6b64b2 tcg: Log the contents of the prologue with -d out_asm
66e61b5 tcg/optimize: fix setcond2 optimization
Anyway I'm just throwing around words and waving my hand, hoping that
someone with actual insight will chime in.
Laszlo
^ permalink raw reply [flat|nested] 15+ messages in thread* 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
2013-05-16 21:46 ` [Qemu-devel] [Bug 1180970] [NEW] " Laszlo Ersek
@ 2013-05-16 22:32 ` Duane Voth
2013-05-16 22:44 ` Laszlo Ersek
2013-05-17 10:20 ` Paolo Bonzini
1 sibling, 1 reply; 15+ messages in thread
From: Duane Voth @ 2013-05-16 22:32 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Bug 1180970, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
Ha, I thought kvm was on by default. Apparently not, qemu -enable-kvm
avoids this issue.
Yes, 0x0000000100000000 with RIP=00000000ffffffe4 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)
[-- Attachment #2: Type: text/html, Size: 461 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2013-05-16 22:32 ` Duane Voth
@ 2013-05-16 22:44 ` Laszlo Ersek
0 siblings, 0 replies; 15+ messages in thread
From: Laszlo Ersek @ 2013-05-16 22:44 UTC (permalink / raw)
To: Duane Voth; +Cc: Bug 1180970, qemu-devel
On 05/17/13 00:32, Duane Voth wrote:
> Ha, I thought kvm was on by default. Apparently not, qemu -enable-kvm
> avoids this issue.
>
> Yes, 0x0000000100000000 with RIP=00000000ffffffe4 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)
Instructions are on the same wiki page, http://wiki.qemu.org/Download
Laszlo
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2013-05-16 21:46 ` [Qemu-devel] [Bug 1180970] [NEW] " Laszlo Ersek
2013-05-16 22:32 ` Duane Voth
@ 2013-05-17 10:20 ` Paolo Bonzini
1 sibling, 0 replies; 15+ messages in thread
From: Paolo Bonzini @ 2013-05-17 10:20 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Duane Voth, Bug 1180970, qemu-devel
Il 16/05/2013 23:46, Laszlo Ersek ha scritto:
> On 05/16/13 21:58, Duane Voth wrote:> 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 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?
>
> I reckon you don't see this with KVM enabled. (Because I don't see it
> with KVM enabled, with my own OVMF builds anyway :), plus the "Trying to
> execute code outside RAM or ROM" message comes from code that strikes me
> as part of TCG.)
>
> It surprises me that RIP=00000000ffffffe4 whereas get_page_addr_code()
> [cputlb.c] logs "at 0x0000000100000000".
>
> The RIP seems to be in OVMF init code.
>
> 0x0000000100000000 is 4G exactly and looks suspicious.
>
> Can you try bisecting TCG between 1.4.0 and current master?
>
> git log --oneline --reverse v1.4.0.. -- tcg \
> | egrep -v 'tcg[-/](arm|ppc|sparc|s390|mips)'
>
> 0b0d332 TCG: Final globals clean-up
> 5e5f07e TCG: Move translation block variables to new context inside tcg_ctx: tb_ctx
> 24537a0 qemu-log: Rename the public-facing cpu_set_log function to qemu_set_log
> e6a7273 tcg: Make 32-bit multiword operations optional for 64-bit hosts
> bbc863b tcg-i386: Always implement 32-bit multiword ops
> d7156f7 tcg: Add 64-bit multiword arithmetic operations
> 4d3203f tcg: Add signed multiword multiplication operations
> 3c51a98 tcg: Implement a 64-bit to 32-bit extraction helper
> 696a8be tcg: Implement multiword multiply helpers
> f6953a7 tcg: Implement multiword addition helpers
> 624988a tcg-i386: Implement multiword arithmetic ops
> f402f38 tcg: Implement muls2 with mulu2
> f1fae40 tcg: Apply life analysis to 64-bit multiword arithmetic ops
> 989b697 qemu-log: default to stderr for logging output
> 0980011 tcg: Document tcg_qemu_tb_exec() and provide constants for low bit uses
> 378df4b Handle CPU interrupts by inline checking of a flag
> 294e466 Use proper term in TCG README
> 2d49754 tcg-optimize: Fold sub r,0,x to neg r,x
> 03fc054 tci: Use 32-bit signed offsets to loads/stores
> 4699ca6 tci: Delete unused tb_ret_addr
> ee79c35 tci: Make tcg temporaries local to tcg_qemu_tb_exec
> 0a9c234 Merge branch 'tci' of git://qemu.weilnetz.de/qemu
> ed60512 tcg: fix deposit_i64 op on 32-bit targets
> d6b64b2 tcg: Log the contents of the prologue with -d out_asm
> 66e61b5 tcg/optimize: fix setcond2 optimization
>
> Anyway I'm just throwing around words and waving my hand, hoping that
> someone with actual insight will chime in.
You also need to add target-i386/ to this list, but yes, bisection
sounds like a plan.
I suggest that you bisect using a new build directory on every
compilation step, something like "rm -rf build; mkdir build; (cd build
&& ../configure --target-list=x86_64-softmmu && make -jNN)".
Paolo
^ permalink raw reply [flat|nested] 15+ messages in thread
* [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
2013-05-16 19:58 [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 Duane Voth
2013-05-16 20:01 ` [Qemu-devel] [Bug 1180970] " Duane Voth
2013-05-16 21:46 ` [Qemu-devel] [Bug 1180970] [NEW] " Laszlo Ersek
@ 2013-05-17 15:35 ` Launchpad Bug Tracker
2013-05-17 15:39 ` Marco Trevisan (Treviño)
` (4 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Launchpad Bug Tracker @ 2013-05-17 15:35 UTC (permalink / raw)
To: qemu-devel
** Branch linked: lp:~3v1n0/unity/gtk-wrapper-icon-info
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [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
2013-05-16 19:58 [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 Duane Voth
` (2 preceding siblings ...)
2013-05-17 15:35 ` [Qemu-devel] [Bug 1180970] " Launchpad Bug Tracker
@ 2013-05-17 15:39 ` Marco Trevisan (Treviño)
2013-05-17 20:03 ` Duane Voth
2013-05-24 21:37 ` Laszlo Ersek
` (3 subsequent siblings)
7 siblings, 1 reply; 15+ messages in thread
From: Marco Trevisan (Treviño) @ 2013-05-17 15:39 UTC (permalink / raw)
To: qemu-devel
** Branch unlinked: lp:~3v1n0/unity/gtk-wrapper-icon-info
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread* 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
2013-05-17 15:39 ` Marco Trevisan (Treviño)
@ 2013-05-17 20:03 ` Duane Voth
2013-05-21 18:16 ` Duane Voth
0 siblings, 1 reply; 15+ messages in thread
From: Duane Voth @ 2013-05-17 20:03 UTC (permalink / raw)
To: qemu-devel
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 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* 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
2013-05-17 20:03 ` Duane Voth
@ 2013-05-21 18:16 ` Duane Voth
0 siblings, 0 replies; 15+ messages in thread
From: Duane Voth @ 2013-05-21 18:16 UTC (permalink / raw)
To: qemu-devel
Ok, somehow the firewall was messed up - it works now. :/
4a6fd938f5457ee161d2acbd9364608a2a68b7a1 is the first bad commit
commit 4a6fd938f5457ee161d2acbd9364608a2a68b7a1
Author: Richard Henderson <rth@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 <rth@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [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
2013-05-16 19:58 [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 Duane Voth
` (3 preceding siblings ...)
2013-05-17 15:39 ` Marco Trevisan (Treviño)
@ 2013-05-24 21:37 ` Laszlo Ersek
2013-05-24 21:49 ` Laszlo Ersek
` (2 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Laszlo Ersek @ 2013-05-24 21:37 UTC (permalink / raw)
To: qemu-devel
** Changed in: qemu
Status: New => In Progress
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [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
2013-05-16 19:58 [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 Duane Voth
` (4 preceding siblings ...)
2013-05-24 21:37 ` Laszlo Ersek
@ 2013-05-24 21:49 ` Laszlo Ersek
2013-05-29 19:05 ` Duane Voth
2016-09-28 14:28 ` T. Huth
7 siblings, 0 replies; 15+ messages in thread
From: Laszlo Ersek @ 2013-05-24 21:49 UTC (permalink / raw)
To: qemu-devel
Proposed patch: http://thread.gmane.org/gmane.comp.emulators.qemu/213023
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [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
2013-05-16 19:58 [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 Duane Voth
` (5 preceding siblings ...)
2013-05-24 21:49 ` Laszlo Ersek
@ 2013-05-29 19:05 ` Duane Voth
2016-09-28 14:28 ` T. Huth
7 siblings, 0 replies; 15+ messages in thread
From: Duane Voth @ 2013-05-29 19:05 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* [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
2013-05-16 19:58 [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 Duane Voth
` (6 preceding siblings ...)
2013-05-29 19:05 ` Duane Voth
@ 2016-09-28 14:28 ` T. Huth
2016-09-28 14:59 ` Duane Voth
7 siblings, 1 reply; 15+ messages in thread
From: T. Huth @ 2016-09-28 14:28 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 15+ messages in thread* 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
2016-09-28 14:28 ` T. Huth
@ 2016-09-28 14:59 ` Duane Voth
0 siblings, 0 replies; 15+ messages in thread
From: Duane Voth @ 2016-09-28 14:59 UTC (permalink / raw)
To: qemu-devel
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 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
^ permalink raw reply [flat|nested] 15+ messages in thread