On Fri, Apr 04, 2014 at 08:34:11PM -0400, Kevin O'Connor wrote:
IMO 'dmidecode -t0' should show what firmware you are running (seabios/ovmf/coreboot/whatever), not something made up by qemu.
Ultimately my preference would be to make a clean break from the existing smbios fw_cfg system as it is too complex, too confusing, and too inflexible. We could implement the above as you suggest, but I fear it would require keeping much of the complexity of the current fw_cfg interface. (It's also a new feature as SeaBIOS doesn't currently put any useful info in type 0.)
I like this idea too: older/current versions of qemu just do what they do, and work with SeaBIOS the way they always have. Future versions just send a completely new fw_cfg message type, which, when encountered by SeaBIOS, causes it to only add in (or edit) type 0, and leave everything else as is.
I don't see anything in the spec that would prohibit it, but I don't think it's done in practice. Given how many different OS parsers there are and their dubious quality, I think we'd want to be as simple as possible and continue to put table 0 at the start. ... The already existing romfile_loader interface seems to provide a nearly complete solution to replace the smbios fw_cfg system. If there is really demand for more firmware info in the type 0 table, why don't we use romfile_loader, have qemu put together a dummy type 0 table, and then have seabios update it in place? Sure, that's ugly, but I'm pretty sure it would be less ugly then keeping the existing smbios fw_cfg system around.
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...
--Gabriel