Hi, > > From the conversation so far, it seems to me that: > > > > - type 0 is best left to the BIOS (user overrides via > > command line at their own risk)
I think it was a bad idea to allow overriding type0 fields in the first place. It also isn't used in practice. I don't think it is a big problem to loose that capability. > > - therefore, the maximum granularity of QEMU-generated > > elements should be full tables of a given type, and > > not the full SMBIOS blob at once (other mechanisms to > > allow the BIOS to insert its own type 0 welcome, but > > so far this seems the most straightforward one). Just an idea: Is the table ordering important? I don't think so. If qemu supplies a blob with all tables except type0, can the firmware simply append a type0 record to the blob supplied by qemu? > I don't agree - I think ultimately we want QEMU to generate the full > SMBIOS table and pass it to the firmware via the romfile_loader > mechanism. I still think the firmware (and *only* the firmware) should supply the type0 table. I also think seabios should fill in something more sensible in there, such as "Vendor: SeaBIOS" and "Version: rel-1.7.4-0-g96917a8-...". > The only thing that has been raised as an issue with this > is one bit in the smbios table (UEFI support). IMO 'dmidecode -t0' should show what firmware you are running (seabios/ovmf/coreboot/whatever), not something made up by qemu. cheers, Gerd