Re: [Qemu-devel] [v2 PATCH 11/13] SMBIOS: Build full type 19 tables

[Gabriel L. Somlo]

On Wed, Mar 12, 2014 at 02:04:50PM -0400, Gabriel L. Somlo wrote:
> On Wed, Mar 12, 2014 at 02:24:54PM +0100, Gerd Hoffmann wrote:
> > You should get identical results with both methods.  It's just that the
> > e820 method is more future proof, i.e. if the numa people add support
> > for non-contignous memory some day we don't have to adapt the smbios
> > code to handle it.
> 
> So, assuming we're staying under 2T, a single T16 array is created
> with handle 0x1000.
> 
> T17 devices are created in increments of 16Gigs, and they all point
> back at the T16 array via their Array Handle field.
> 
> One T19 "array mapped address" is created for below-4g memory, and a
> second one for above-4g.
> 
> T20 is where the fun begins. Apparently (assuming over-4g ram),
> two T20s are created to split the first t17 device's memory into
> the below-4g portion and the above-4g portion.
> 
> From then on, one T20 corresponds to one T17. So we get X+1 T20s for
> each X T17s (with the first two T20s pointing at the first T17,
> and T20(x+1) pointing at T17(x) for every x after the first).
> 
> Any idea how I can best anticipate accomodating numa on top of this ?
> 
> Presumably there will be additional e820 entries resulting in extra
> T19s, but what will that do to the T17s and the T20s ? :)

Thinking in small increments here, sorry for the self-reply:

Do you anticipate a new field in e820_entry, perhaps hinting at which
CPU the memory belongs to ?

Even now, assuming type==E820_RAM, I know you're putting in exactly
one or two entries (below-4g and above-4g). But if I use e820 in
smbios, am I OK assuming there will always be precisely one entry
for which (start+lengh <= 4G) ?

At least with the current arithmetic I'm working directly with
[below|above]_4g, so there's no way to mistakenly assume the wrong
thing, until we explicitly add in NUMA support :)

Thanks,
--G