src/smbios.c has
u64 memsize = RamSizeOver4G; if (memsize) memsize += 0x100000000ull; else memsize = RamSize;
RamSizeOver4G = "total ram" - "start of pci hole" (e.g. 0xe0000000 in qemu, 0xc0000000 in bochs) Adding 4GB is wrong. With 33 GB of RAM i end up with 16+16+2 instead of 16+16+1 in smbios tables. The patch below fixes it for me.
above_4g_mem_size in qemu is a possible misnomer.
- Sebastian
--- a/src/smbios.c +++ b/src/smbios.c @@ -405,11 +405,7 @@ smbios_init(void) int cpu_num; for (cpu_num = 1; cpu_num <= MaxCountCPUs; cpu_num++) add_struct(4, p, cpu_num); - u64 memsize = RamSizeOver4G; - if (memsize) - memsize += 0x100000000ull; - else - memsize = RamSize; + u64 memsize = RamSize + RamSizeOver4G; memsize = memsize / (1024 * 1024); int nr_mem_devs = (memsize + 0x3fff) >> 14; add_struct(16, p, memsize, nr_mem_devs);
On Wed, Jan 06, 2010 at 09:13:13PM +0100, Sebastian Herbszt wrote:
RamSizeOver4G = "total ram" - "start of pci hole" (e.g. 0xe0000000 in qemu, 0xc0000000 in bochs)
The intent of RamSizeOver4G is to list the amount of ram mapped above 0x100000000. So, if one specified 4096MB of ram, I'd expect qemu to map it so that SeaBIOS had RamSize=0xe0000000 and RamSizeOver4G=0x10000000.
Adding 4GB is wrong. With 33 GB of RAM i end up with 16+16+2 instead of 16+16+1 in smbios tables. The patch below fixes it for me.
I'm not sure what smbios is expecting - if it's looking for the addresses of mapped memory then the current code looks correct (in the scenario above, memory is mapped up to 0x110000000). If it's looking for the total memory, then I agree your change makes sense (in the above scenario, the total ram is 0x100000000).
-Kevin
On Wed, Jan 06, 2010 at 05:48:29PM -0500, Kevin O'Connor wrote:
On Wed, Jan 06, 2010 at 09:13:13PM +0100, Sebastian Herbszt wrote:
RamSizeOver4G = "total ram" - "start of pci hole" (e.g. 0xe0000000 in qemu, 0xc0000000 in bochs)
The intent of RamSizeOver4G is to list the amount of ram mapped above 0x100000000. So, if one specified 4096MB of ram, I'd expect qemu to map it so that SeaBIOS had RamSize=0xe0000000 and RamSizeOver4G=0x10000000.
Adding 4GB is wrong. With 33 GB of RAM i end up with 16+16+2 instead of 16+16+1 in smbios tables. The patch below fixes it for me.
I'm not sure what smbios is expecting - if it's looking for the addresses of mapped memory then the current code looks correct (in the scenario above, memory is mapped up to 0x110000000). If it's looking for the total memory, then I agree your change makes sense (in the above scenario, the total ram is 0x100000000).
It looks like different tables looks for different things,
Table 16 describes how much memory board supports (should be bigger or equal to RamSizeOver4G+RamSize if hot plug memory is not supported I guess). Just picking a big enough number is good enough.
Table 17 describes how much memory installed in each DIMM. Sum of all sizes should be equal to RamSizeOver4G+RamSize.
Table 19 spec says it provides the address mapping for a Physical Memory Array (table 16). One structure is present for each contiguous address range described. Nobody know what this means. I checked 3 computers and got 3 different interpretations:
On computer with 4G memory: Handle 0x0026, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x0012FFFFFFF Range Size: 4864 MB Physical Array Handle: 0x0025 Partition Width: 0 Here Ending Address is RamSizeOver4G + 4G
On computer with 16G memory: Handle 0x003D, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x003FFFFFFFF Range Size: 16 GB Physical Array Handle: 0x0024 Partition Width: 0 Here Ending Address is RamSizeOver4G+RamSize
On another computer with 16G memory: Handle 0x0045, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x3C3FFFFFFFF Range Size: 3856 GB Physical Array Handle: 0x003C Partition Width: 0 Here it is just a huge number.
So apparently nobody understands what this table is about.
Table 20 looks like it maps physical address ranges to DIMMs and physical address ranges is from 0 to RamSizeOver4G+RamSize. One of my test machines does not have this table at all.
Whatever change we do to smbios table we need to validate it with SVVP test first.
-- Gleb.
Gleb Natapov wrote:
On Wed, Jan 06, 2010 at 05:48:29PM -0500, Kevin O'Connor wrote:
On Wed, Jan 06, 2010 at 09:13:13PM +0100, Sebastian Herbszt wrote:
RamSizeOver4G = "total ram" - "start of pci hole" (e.g. 0xe0000000 in qemu, 0xc0000000 in bochs)
The intent of RamSizeOver4G is to list the amount of ram mapped above 0x100000000. So, if one specified 4096MB of ram, I'd expect qemu to map it so that SeaBIOS had RamSize=0xe0000000 and RamSizeOver4G=0x10000000.
Adding 4GB is wrong. With 33 GB of RAM i end up with 16+16+2 instead of 16+16+1 in smbios tables. The patch below fixes it for me.
I'm not sure what smbios is expecting - if it's looking for the addresses of mapped memory then the current code looks correct (in the scenario above, memory is mapped up to 0x110000000). If it's looking for the total memory, then I agree your change makes sense (in the above scenario, the total ram is 0x100000000).
It looks like different tables looks for different things,
Table 16 describes how much memory board supports (should be bigger or equal to RamSizeOver4G+RamSize if hot plug memory is not supported I guess). Just picking a big enough number is good enough.
I would assume it should be RamSizeOver4G+RamSize if no spare memory device slots are available (e.g. hotplugging not supported). Else picking a "big enough number" is good enough indeed, 128 GB or something like that maybe. Then it needs to define spare memory device slots tho, e.g. with 16 GB max. per slot we end up with 8 slots. In a 4GB config it would be slot 1 with 4GB and slots 2-8 with 0 GB. Might as well change the location value from "Other" to "System board or memory" too.
Table 17 describes how much memory installed in each DIMM. Sum of all sizes should be equal to RamSizeOver4G+RamSize.
This currently is wrong in SeaBIOS (16+16+2 in my config). Even if memory consumed by the pci hole is mapped above 4 GB it does not affect the physical memory layout.
Could also fix the error information handle value from invalid 0x0 to 0xfffe.
- Sebastian
-
Gleb Natapov -
Kevin O'Connor -
Sebastian Herbszt