[Etherboot-developers] Memory allocation

[Michael B. <mb...@fe...>]

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.

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?)

4. Etherboot heap.  This gets placed in the largest contiguous block in 
   memory.  At the moment, nothing uses it.

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.

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.


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).

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).

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).

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

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".


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.

Michael