On Fri, Mar 14, 2014 at 06:51:05PM +0100, Igor Mammedov wrote: > > 1. is it safe to assume that E820_RAM (start_addr, size) entries are > > non-overlapping and sorted by increasing start_addr ? > They might overlap, grep for e820_add_entry(). If you interested in > what kernel does with such table look for sanitize_e820_map() there. > > Does SMBIOS/t17 actually care about shadowing parts of it by something > else in unrelated e820? > > > > > 2. will there always be a below-4g entry ? if so, will it *and* the > > next entry automatically be assumed to belong to the first node, and > > only subsequently will there be one E820_RAM entry per node (for nodes > > 2, 3, etc) ? > Once we have DIMMDevices, I'm planning to convert below-4g and above-4g to > a set of DIMMDevices, there will be at least 1 device per node but there could > be more of them to satisfy different backend requirements like hugepage > size, alignment, e.t.c. > > BTW why do we care how smbios tables are build in relation to NUMA mapping, > they seem to be totally independent.
Here's the context: I'm working on migrating smbios table generation into QEMU, see: http://lists.nongnu.org/archive/html/qemu-devel/2014-03/msg02473.html Currently, to generate memory-related tables (t16, 17, 19, and 20), SeaBIOS starts with ram_size, below_4g_mem_size, and above_4g_mem_size, and does the following: 1. create a t16 to reflect all of ram_size (this currently only works up to 2T, btw). 2. create t17s in increments of 16G (max. t17 size allowed by currently supported smbios version, 2.4 3. Create a t19 for [0..below_4g_mem_size], and, if applicable, another one for [4G..(4G+above_4g_mem_size)]. 4. Create t20s, each of which needs a pointer to a t17 and a t19, so: - first t20 goes from [0..below_4g_mem_size] and points at the first t17 and at the below_4g t19 - second t20 goes from [4G..(16G - below_4g_mem_size)] and still points at the first t17, but at the above_4g t19; - further t20s all point at the above_4g t19 and at one t17 each, starting with the *second* t17. Kinda like this: 16G 16G 16G 16G ------------------------------ <-t17-> t17 t17 ... t17 dimm devices t20 t20 t20 t20 ... t20 device address maps t19 <----------t19----------> memory address maps (E820_RAM entries ?) ------------------------------ <4G <------- over-4g -------> t17s are "devices" or dimms, t20s are "device address maps", and t19s are "memory address maps" or somesuch. Currently, t19s exactly match the exactly two E820_RAM type entries the e820 table, and the subject under discussion is whether or not to create one smbios t19 per E82_RAM entry from the e820 table, instead of going with just two for below- vs above- 4Gig. And from there, how to apportion more t20s and t17s to the additional t19s. Sounds like if E820_RAM segments are allowed to overlap, creating t19s for each one of them might not work out. But then again, it may be that I'm missing something, which is probably a more likely scenario :) :) Thanks, --Gabriel
