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
