Re: [Etherboot-developers] Memory allocation

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> Memory allocation within Etherboot seems to suffer from several problems 
> at the moment.  As far as I can tell, we have the following memory ranges 
> being used:
> 
> 1. Etherboot text.  This will be at RELOCADDR (=0x20000) if -DRELOCATE is
>    not defined, otherwise somewhere towards the top of available RAM.  
>    (Will always be within an even megabyte, i.e. A20=0).
> 
> 2. Etherboot protected-mode stack.  I think this is within the Etherboot 
>    text, somebody please confirm/correct me on this.

Actually a better way of looking at Etherboot text and the stack is:
Etherboot text+data+bss  They are all of a predetermined fixed size,
and the protected mode stack is allocated in the bss.  The bss is important
because it takes no space in the etherboot image but it is allocated
statically at build time.

static char buf[255];  or any other static variable without an initializer
will be allocated in the bss.

> 3. Etherboot real-mode stack.  This is always at the top of free base 
>    memory (as defined by 40:13), provided that Etherboot is the only thing 
>    allocating base memory.
> 
>    NB. Other code may allocate base memory by changing the counter at
>    40:13.  We should really recalculate the real-mode stack top each time
>    we make a _real_call, based on the current contents of 40:13.  Is there 
>    any reason why we can't do this?  (I'm thinking of LinuxBIOS in 
>    particular; does this use the same 40:13 counter?)

LinuxBIOS does not use 40:13 at the present time.  In fact the only
interface to the outside world (Besides the simple LinuxBIOS table)
visible when running etherboot is etherboot itself.

Care needs to be take because I'm not certain 40:13 is reliable.  I
know there are several cases that do BIOS calls to get this
information.  And the linux kernel explicitly does not read it with
a comment about it being unreliable.
 
> 4. Etherboot heap.  This gets placed in the largest contiguous block in 
>    memory.  At the moment, nothing uses it.

The multicast protocol drivers use it.  For most things static
allocation is sufficient and when static allocation works it is safer.
Since packets can come in a random order during multicast reception we
may not have enough information unless we allocate a static buffer for
the file we are downloading.

> 5. Allocated base memory, from 640K down to [40:13]k.  Includes the BIOS 
>    EPDA.
> 
> The interaction of these five areas with prep_segment() has the following 
> problems:
> 
> a. No checks are made for (3).  prep_segment will happily trash the 
>    real-mode stack and _real_call will happily walk all over an area that
>    prep_segment has prepared.

Correct.  That was an after thought.
 
> b. If heap (4) or base memory (5) is allocated after the first call to 
>    prep_segment, it's possible that it will allocate memory that 
>    prep_segment() has already checked is free and prepared.

Correct.  So far all of the heap allocation is just for the multicast
case when we cannot incrementally load the image.  So it all happens
during processing of the first packet.

> In addition, there seems to be an assortment of other mechanisms that 
> programs may use to deal with memory allocation: BIOS PMM, Int 15,87, 
> E820-map reading a la Etherboot etc.  Currently Etherboot makes no attempt 
> to handle or cooperate with any of these; if anything other than Etherboot 
> is allocating memory then there's a high chance of a collision.
> 
> MEMDISK contains routines that, AFAICT, allow us to fake the E820 map, so 
> that we could mark as reserved any regions that we have allocated.  
> Questions:
> 
> 1. Would this be sufficient to prevent other entities treading on 
>    Etherboot?  (I'm guessing yes).

Likely.

> 2. Do we have to do all our memory allocation and E820 map modification 
>    *before* we allow any other entity that might allocate memory to 
>    execute?  (I'm guessing yes).

That would be tricky.  The current assumption is that etherboot owns
the machine.  We may need to rescan the map.

Given that in the worst case we don't know where a packet needs to go
into memory until we read it.  I would say the general etherboot case
is that it needs to do most of the allocation first.

> 3. What if another entity is also faking the E820 map?  (I'm guessing that
>    this is not a problem as long as the other entity also does (2)). 
> 
> 4. How do we avoid treading on other entities?  (In particular: the 
>    Intel UNDI driver seems to install something just above the 1MB mark.  
>    prep_segment() then obliterates this, because it can't tell that the
>    region is in use).

Very good question.  It looks like we need to rescan things (at least
in the UNDI driver case.

> 5. Would it take into account the BIOS PMM, if it exists?

Possibly.  I don't recall what that is...
If it is BIOS services for allocating memory above 1MB then that would
be a good idea.
 
> 6. How do we tidy up before passing control to the loaded program?  We 
>    don't always want to free everything; if it's a menu program then we 
>    need to keep Etherboot "hidden".

This is the biggest reason I dislike callbacks, there is a lot of
weird cooperation needed to get everything working.

> Comments, suggestions, ideas welcome.  This is currently the only thing 
> stopping the UNDI driver from working.  It needs to be sorted out before 
> Etherboot can reliably co-exist with other boot ROMs (e.g. PXE ROMs are 
> likely to install things into extended memory) and it's a prerequisite of 
> PXE-on-Etherboot.


I hope this helps.

Eric