From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNj9k-00014N-HD for qemu-devel@nongnu.org; Wed, 12 Mar 2014 09:25:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNj9e-0004hN-Ik for qemu-devel@nongnu.org; Wed, 12 Mar 2014 09:25:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNj9e-0004gN-Ar for qemu-devel@nongnu.org; Wed, 12 Mar 2014 09:25:06 -0400 Message-ID: <1394630694.17393.38.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Wed, 12 Mar 2014 14:24:54 +0100 In-Reply-To: <20140312130556.GZ17184@ERROL.INI.CMU.EDU> References: <1394532186.22422.24.camel@nilsson.home.kraxel.org> <1394550989-693-1-git-send-email-somlo@cmu.edu> <1394550989-693-12-git-send-email-somlo@cmu.edu> <1394612838.17393.19.camel@nilsson.home.kraxel.org> <20140312130556.GZ17184@ERROL.INI.CMU.EDU> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [v2 PATCH 11/13] SMBIOS: 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, lersek@redhat.com On Mi, 2014-03-12 at 09:05 -0400, Gabriel L. Somlo wrote: > On Wed, Mar 12, 2014 at 09:27:18AM +0100, Gerd Hoffmann wrote: > > I think we should just use e820_table (see pc.c) here. Loop over it and > > add a type 19 table for each ram region in there. > > I'm assuming this should be another post-Seabios-compatibility patch, > at the end of the series, and I should still do the (start,size) > arithmetic cut'n'pasted from SeaBIOS first, right ? 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. cheers, Gerd