From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WO7gI-0000F4-L2 for qemu-devel@nongnu.org; Thu, 13 Mar 2014 11:36:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WO7gC-0004fn-Ix for qemu-devel@nongnu.org; Thu, 13 Mar 2014 11:36:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WO7gC-0004fX-Bq for qemu-devel@nongnu.org; Thu, 13 Mar 2014 11:36:20 -0400 Date: Thu, 13 Mar 2014 16:36:12 +0100 From: Igor Mammedov Message-ID: <20140313163612.4cf21ade@nial.usersys.redhat.com> In-Reply-To: <20140313143751.GH17184@ERROL.INI.CMU.EDU> References: <20140312215528.GF17184@ERROL.INI.CMU.EDU> <1394697892.23859.21.camel@nilsson.home.kraxel.org> <20140313143751.GH17184@ERROL.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] SMBIOS vs. NUMA (was: Build full type 19 tables) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: agraf@suse.de, qemu-devel@nongnu.org, armbru@redhat.com, alex.williamson@redhat.com, kevin@koconnor.net, Gerd Hoffmann , lersek@redhat.com On Thu, 13 Mar 2014 10:37:52 -0400 "Gabriel L. Somlo" wrote: > On Thu, Mar 13, 2014 at 09:04:52AM +0100, Gerd Hoffmann wrote: > >> Should we just assert((ram_size >> 10) < 0x80000000), and officially > >> limit guests to < 2T ? > > No. Not fully sure what reasonable behavier would be in case more than > > 2T are present. I guess either not generating type16 entries at all or > > simply fill in the maximum value we can represent. > > Well, there's an "extended maximum capacity" field available starting > with smbios v2.7, which is an uint64_t counting bytes. Bumping the few > other types up to 2.7 shouldn't be too onerous, but I have no idea how > well the various currently supported OSs would react to smbios suddenly > going v2.7... > > > > Then, a type20 node is assigned to the sub-4G portion of the first > > > Type17 "device", and another type20 node is assigned to the over-4G > > > portion of the same. > > > > > > From then on, type20 nodes correspond to the rest of the 16G-or-less > > > type17 devices pretty much on a 1:1 basis. > > > > Hmm, not sure why type20 entries are handled the way they are. I think > > it would make more sense to have one type20 entry per e820 ram entry, > > similar to type19. > > Type20 entries have pointers to type17 (memory_device_handle) and > type19 (memory_array_mapped_address_handle). Which, if you turn it > upside down could be interpreted as "every type 17 dimm needs (at > least) a type20 device mapped address to point at it". > > > > If the e820 table will contain more than just two E820_RAM entries, > > > and therefore we'll have more than the two Type19 nodes on the bottom > > > row, what are the rules for extending the rest of the figure > > > accordingly (i.e. how do we hook together more Type17 and Type20 nodes > > > to go along with the extra Type19 nodes) ? > > > > See above for type19+20. type17 represents the dimms, so where the > > memory is actually mapped doesn't matter there. Lets simply sum up all > > memory, then split into 16g pieces and create a type17 entry for each > > piece. At least initially. > > That's pretty much what happens now. If we decide to use e820 instead > of simply (below_4g, above_4g), I'd like add some sort of assertion > that would alert anyone who might start adding extra entries into e820 > beyond the current two (below_4g and above_4g) :) After memory hotplug is in I might add e820 entries after above_4g for present at boot hotpluggable DIMMDevices. They would have 1:1 mapping i.e. t19<-t20<-t17 and belong only to 1 node.