On Mon, Nov 14, 2011 at 01:50:05AM +0000, Julian Pidancet wrote:
Some programs or ROMs like iPXE rely on the memory size field present in the BDA instead of e820 to relocate sections at the end of the low memory. Xen's hvmloader places an ACPI info table at 0x9F000 at the end of the usable RAM in low memory (just before the EBDA). The e820 table gets altered accordingly to protect the area where the table lives, but a ROM like iPXE only takes into account the memory size field in the BDA and consequently corrupts the table when relocating itself.
That wont work reliably - SeaBIOS (and option roms) can grow the EBDA. It's not realistic to put a whole in the middle of the first 640k.
[...]
diff --git a/src/memmap.c b/src/memmap.c index 20ccae0..36750f5 100644 --- a/src/memmap.c +++ b/src/memmap.c @@ -7,6 +7,7 @@ #include "memmap.h" // struct e820entry #include "util.h" // dprintf.h #include "biosvar.h" // SET_EBDA +#include "config.h" // CONFIG_*
/**************************************************************** @@ -133,6 +134,34 @@ add_e820(u64 start, u64 size, u32 type) //dump_map(); }
+// Try to find the size of the usable RAM memory in the +// first megabyte of RAM. +u32 +get_lowram_size(void) +{
- u32 lowram_end = 0;
- int i;
- for (i=0; i<e820_count; i++) {
struct e820entry *e = &e820_list[i];
u64 e_end = e->start + e->size;
if (e->type != E820_RAM)
continue;
if (e_end <= 0x100000 && /* 1M */
e_end > lowram_end)
Shouldn't this read (e_end <= BUILD_LOWRAM_END)? Otherwise, if for some strange reason an e820 entry pointed to ram above 0xa0000 but below 1meg, it would break things.
[...]
--- a/src/post.c +++ b/src/post.c @@ -82,18 +82,21 @@ init_bda(void) struct bios_data_area_s *bda = MAKE_FLATPTR(SEG_BDA, 0); memset(bda, 0, sizeof(*bda));
- int esize = EBDA_SIZE_START;
- SET_BDA(mem_size_kb, BUILD_LOWRAM_END/1024 - esize); u16 ebda_seg = EBDA_SEGMENT_START; SET_BDA(ebda_seg, ebda_seg);
As above, this doesn't look right - SeaBIOS will still locate the EBDA at 9fc00 and nothing will stop it from growing it over the 9f000 area.
-Kevin
On Mon, Nov 14, 2011 at 1:11 AM, Kevin O'Connor kevin@koconnor.net wrote:
That wont work reliably - SeaBIOS (and option roms) can grow the EBDA. It's not realistic to put a whole in the middle of the first 640k.
When you say "grow" do you mean grow downwards ? Because if not, the ACPI info structure lives in 9F000, so there shouldn't be any problem reporting the 0-9F000 range as the memory size in the BDA.
[...]
diff --git a/src/memmap.c b/src/memmap.c index 20ccae0..36750f5 100644 --- a/src/memmap.c +++ b/src/memmap.c @@ -7,6 +7,7 @@ #include "memmap.h" // struct e820entry #include "util.h" // dprintf.h #include "biosvar.h" // SET_EBDA +#include "config.h" // CONFIG_*
/**************************************************************** @@ -133,6 +134,34 @@ add_e820(u64 start, u64 size, u32 type) //dump_map(); }
+// Try to find the size of the usable RAM memory in the +// first megabyte of RAM. +u32 +get_lowram_size(void) +{
- u32 lowram_end = 0;
- int i;
- for (i=0; i<e820_count; i++) {
- struct e820entry *e = &e820_list[i];
- u64 e_end = e->start + e->size;
- if (e->type != E820_RAM)
- continue;
- if (e_end <= 0x100000 && /* 1M */
- e_end > lowram_end)
Shouldn't this read (e_end <= BUILD_LOWRAM_END)? Otherwise, if for some strange reason an e820 entry pointed to ram above 0xa0000 but below 1meg, it would break things.
My bad, I just realized that. Maybe a more correct (and simpler) approach would be to look for the range marked as RAM which starts at 0x0 and simply use its size (and check that it doesn't go past 0xA0000). Would that sound right ?
[...]
--- a/src/post.c +++ b/src/post.c @@ -82,18 +82,21 @@ init_bda(void) struct bios_data_area_s *bda = MAKE_FLATPTR(SEG_BDA, 0); memset(bda, 0, sizeof(*bda));
- int esize = EBDA_SIZE_START;
- SET_BDA(mem_size_kb, BUILD_LOWRAM_END/1024 - esize);
u16 ebda_seg = EBDA_SEGMENT_START; SET_BDA(ebda_seg, ebda_seg);
As above, this doesn't look right - SeaBIOS will still locate the EBDA at 9fc00 and nothing will stop it from growing it over the 9f000 area.
The EBDA is a standard bios structure, can't we safely assume that it's size will hardly change ? If not, would you suggest that this ACPI info structure should be placed at a different location ? The problem with this is that it has to be in a location with a fixed address, and preferably in a location which is accessible by any AML interpreter.