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
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
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
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
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
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
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
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,
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
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
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
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
13 matches
Mail list logo
