[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Stack corruption problem with SeaBIOS/gPXE under QEMU

From: Avi Kivity
Subject: Re: [Qemu-devel] Stack corruption problem with SeaBIOS/gPXE under QEMU
Date: Mon, 16 Nov 2009 16:02:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

On 11/16/2009 03:36 PM, Avi Kivity wrote:
On 11/14/2009 09:47 PM, Kevin O'Connor wrote:

On Thu, Nov 12, 2009 at 01:20:58PM +0200, Naphtali Sprei wrote:
I've found a problem with the usage of SeaBIOS/gPXE in Qemu.  The
scenario is when failing to boot from network and falling back to
booting from hard-disk (-boot nc).  The cause of the problem is that
both SeaBIOS and gPXE (in it's installation phase) uses same stack
area, 0x7c00.  The gPXE code corrupts the SeaBIOS stack, so when
gPXE returns to SeaBIOS chaos occurs.

Output: "qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000eb300000"
Thanks for reporting this.

We can move the SeaBIOS stack, but it's not clear to me where to move
it to.  Bochs bios puts the top of the stack at 0x10000, but this
could potentially conflict with the OS load to 0x7c00.  So, in SeaBIOS
the top of stack was moved to 0x7c00 to prevent this conflict.

Maybe the gPXE developers know where the bios typically places its

However, I'm not sure why gPXE doesn't just use the stack it was
given, or allocate the stack space it needs with PMM.

Something that is likely related, I am seeing reboot failures in seabios's pmm_free. Immediately after loading gpxe, seabios is in an endless loop there, likely due to memory corruption.

This is with -smp 2, rebooting Fedora 9 after installation.

With gpxe disabled, rebooting works as expected.

Note the tests were performed with the stack at 64K to avoid triggering the known issue.

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]