[Etherboot-developers] Memory allocation
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: Michael B. <mb...@fe...> - 2003-05-23 16:20:12
|
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 |