qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [v2 PATCH 11/13] SMBIOS: Build full type 19 tables
Date: Wed, 12 Mar 2014 14:04:50 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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 ? :)

Thanks,
--Gabriel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]