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
4=0668
On Thu, May 16, 2013 at 11:59 AM, Duane Voth 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 interesti
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 troub
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
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
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, th
Ok, somehow the firewall was messed up - it works now. :/
4a6fd938f5457ee161d2acbd9364608a2a68b7a1 is the first bad commit
commit 4a6fd938f5457ee161d2acbd9364608a2a68b7a1
Author: Richard Henderson
Date: Thu Jan 10 13:29:23 2013 -0800
target-i386: Tidy prefix parsing
Avoid duplicati
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 w
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
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
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 p
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
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
13 matches
Mail list logo
