From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXAcE-00071M-Ey for qemu-devel@nongnu.org; Mon, 07 Apr 2014 10:33:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXAc8-0006h5-9q for qemu-devel@nongnu.org; Mon, 07 Apr 2014 10:33:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXAc8-0006h1-1F for qemu-devel@nongnu.org; Mon, 07 Apr 2014 10:33:32 -0400 Message-ID: <5342B736.1090007@redhat.com> Date: Mon, 07 Apr 2014 16:33:26 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <533A7B60.7080408@redhat.com> <20140401143902.GA6462@morn.localdomain> <533ADF7D.6010804@redhat.com> <20140401184726.GH9466@ERROL.INI.CMU.EDU> <20140401202832.GA24065@morn.localdomain> <1396451097.31715.20.camel@nilsson.home.kraxel.org> <20140405003410.GA13086@morn.localdomain> <20140405011513.GB31429@foober.ini.cmu.edu> <20140405022632.GA21769@morn.localdomain> <1396854596.5001.17.camel@nilsson.home.kraxel.org> <20140407141435.GA22185@morn.localdomain> In-Reply-To: <20140407141435.GA22185@morn.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor , Gerd Hoffmann Cc: "Gabriel L. Somlo" , seabios@seabios.org, qemu-devel@nongnu.org On 04/07/14 16:14, Kevin O'Connor wrote: > On Mon, Apr 07, 2014 at 09:09:56AM +0200, Gerd Hoffmann wrote: >>>> The only fly in this ointment may be that type 0 doesn't have a fixed >>>> length that could be edited in place, if you consider the various >>>> strings that get tacked on to the end of it. So you'd still have to >>>> slide the rest of the smbios payload left or right to shrink or >>>> enlarge the type 0 blob, depending on how you modify the various >>>> strings it contains... >>> >>> The dummy type 0 subtable that QEMU generates can have dummy space >>> padded strings that the firmware can overwrite. Until recently, the >>> max size smbios string was 64 bytes, so that size could be used. (As >>> above, I admit that this is ugly, but the alternatives also seem >>> ugly.) Another option would be to just leave the strings at a QEMU >>> default as that's no different from what SeaBIOS does today. >> >> I don't think we need to make it that complicated. smbios tables don't >> have any references, right? I mean any references which would need a >> fixup (such as table pointers in RSDP in acpi) and therefore would need >> the romfile_loader. The string references within a table are relative >> don't need special care. > > The smbios anchor table needs to have the address of the main smbios > table. It would be preferable to get the anchor table from qemu as > the anchor table has the smbios version info. > > But, anchor table aside, you are correct. > >> Gabriel has code to generate all tables needed in qemu meanwhile, so I >> think we can simply have a blob in fw_cfg with all tables (except >> type0). firmware generates type0 table like it does today, then simply >> appends the fw_cfg blob as-is, then appends a end-of-tables marker. >> Done. >> >> OVMF probably would have to parse the blob, split it into tables, then >> install them one by one. But I suspect that will be less code than >> dealing with the complex smbios fw_cfg interface we have today ... > > How about having QEMU produce the smbios table with a dummy type0 > table and then both seabios and ovmf can replace the type0 table if > desired. After all, if OVMF is splitting the blob into tables, it can > just as easily replace type0 as append it. > > This way, the QEMU output is technically complete. And if someone > wishes to code up SeaBIOS to do the type0 replace (I'm not convinced > it's even necessary) then at least that SeaBIOS code could be used on > coreboot as well. Works for me. Thanks Laszlo