On Fri, Apr 04, 2014 at 09:15:14PM -0400, Gabriel L. Somlo wrote: > 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.
Right. > > 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... 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. -Kevin
