On Mon, Apr 07, 2014 at 02:05:21PM -0400, Gabriel L. Somlo wrote:
> On Mon, Apr 07, 2014 at 11:23:44AM -0400, Kevin O'Connor wrote:
> > So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file
> > with the valid anchor table (the address pointer can be just set to
> > zero), and an smbios table file with the complete set of smbios tables
> > formatted according to the smbios spec.  SeaBIOS can then use the
> > existence of one of these new files to determine if it should deploy
> > (and optionally modify) them or if it should use the old smbios
> > generation code.
> 
> Oh, OK. Right now we have (in qemu):
> 
> #define SMBIOS_FIELD_ENTRY 0
> #define SMBIOS_TABLE_ENTRY 1
> 
> I will be adding (actually, migrating to):
> 
> #define SMBIOS_ANCHOR_ENTRY 2 /* for the smbios entry point table */
> #define SMBIOS_FULLTABLE_ENTRY 3 /* for the blob containing all types */

No - don't do that.  Lets leave the existing smbios fw_cfg entry
(0x8001) unchanged.  Instead, introduce two new fw_cfg files using the
fw_cfg_add_file() interface (eg, "etc/smbios/smbios-anchor" and
"etc/smbios/smbios-tables").

[...]
> I can add such a structure for the anchor/entrypoint table and for the
> full blob-of-tables payload, in which I can tell you how big type 0 is,
> so the BIOS (SeaBIOS/TianoCore) side surgery can be made that much
> easier...

It's trivial for the firmware to calculate this on its own, so I
recommend just putting the anchor table and main tables unmodified in
their respective fw_cfg files.

-Kevin

Reply via email to