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

[Avi Kivity]

On 11/16/2009 03:36 PM, Avi Kivity wrote:
> On 11/14/2009 09:47 PM, Kevin O'Connor wrote:
> > Hi,
> >
> > 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
> > stack.
> >
> > 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