Re: [Qemu-devel] SMBIOS vs. NUMA (was: Build full type 19 tables)

[Gabriel Somlo]

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