[SeaBIOS] Running out of space in e/f-segments

Gleb Natapov gleb at redhat.com
Mon Aug 23 09:30:51 CEST 2010

On Mon, Aug 23, 2010 at 08:37:16AM +0300, Avi Kivity wrote:
>  On 08/23/2010 01:57 AM, Kevin O'Connor wrote:
> >On Sun, Aug 22, 2010 at 09:18:43PM +0300, Avi Kivity wrote:
> >>  On 08/22/2010 08:40 PM, Kevin O'Connor wrote:
> >>>On Sun, Aug 22, 2010 at 08:07:53PM +0300, Avi Kivity wrote:
> >>>>I see that ld has some support for overlays, perhaps we can use that?
> >>>The overlay support is basically just another way of manipulating the
> >>>run-time addresses of the code at build time.  Unfortunately, it can
> >>>only specify static addresses, and I don't think there is any safe
> >>>static address that can be used (outside of 0xc0000-0xfffff).
> >>Is that not useful?  We can push, say the IDE and virtio drivers to
> >>overlay the same address range in the e/f segments, and have the
> >>stubs pull them in as necessary.
> >I guess you're describing a way of swapping parts of the BIOS in.  It
> >could be made to work, but seems very complicated.
> That's what overlay is, it used to be a hot method way back.  Why do
> you think it's complicated?  There's some support for it in ld.
It is not hot method any more for a reason though :) It is complicated
because you need to decide at build time what can overlay with what.

> >Relocating the code isn't that bad.  It should just be a matter of
> >storing which parts of the code rely on a fixed address, and then
> >updating those addresses at runtime.  Something like:
> >
> >     // Info provided by build
> >     extern u32 Relocs[];
> >     extern u32 NumRelocs;
> >     extern void *OrigCodeAddr;
> >     extern u32 CodeSize;
> >
> >     // Relocation code.
> >     memcpy(newaddr, OrigCodeAddr, CodeSize);
> >     for (i=0; i<NumRelocs; i++)
> >         *(u32*)(newaddr + Relocs[i]) += (newaddr - OrigCodeAddr);
> >
> >If the code can be relocated, it should be okay to put it at the top
> >of high memory.  Relocating should be more transparent than "swapping"
> >to developers, as it wouldn't impose any limits on what can code can
> >call other code.
> Overlays are transparent too, you typically have stubs for overlaid
> code which call the overlay manager to swap the code in if
> necessary.  These stubs are generated automatically.
> Relocation should work as well, and indeed has less constraints, but
> needs more build support.
> -- 
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS at seabios.org
> http://www.seabios.org/mailman/listinfo/seabios


More information about the SeaBIOS mailing list