On Tue, Feb 18, 2014 at 02:17:29PM -0500, Gabriel L. Somlo wrote:
Sending a patch against QEMU would have definitely been my first choice, by a wide margin :) But after studying the hw/i386/smbios.c source file in QEMU for a while, I walked away with the impression that all it really tries to do is edit a few of the Type 0 and Type 1 fields, and that the hand-over logic between QEMU and SeaBIOS is not ready for prime time yet.
The current mechanism for passing smbios from QEMU to SeaBIOS is horrible.
So I sent the patch to SeaBIOS, where it seems to do what I want it to :)
I could try to hack at the QEMU smbios source file to try to find where the problem lies (at least why handover to SeaBIOS doesn't work as expected), but I'm not sure providing command line flags for inputting each record type individually is a scalable way to move forward.
In my opinion, generating the entire smbios table in QEMU and using the "romfile_loader" mechanism (see seabios src/fw/romfile_loader.c) would be the preferred solution. I understand that this is more than you signed up for.
Perhaps if there were a DMI/SMBIOS compiler (the reverse action of "dmidecode --from-dump", something that would take a text "source" table and generate a .bin from it), we could focus on getting the "-smbios file=<foo>" bit working correctly, and we could provide instructions in the docs on how users can build their own smbios tables.
But I couldn't find anything out there that would "compile" a smbios table from some type of human-readable (ascii) form...
Any thoughts ?
Thanks, --Gabriel
PS. I tried the patched SeaBIOS (with v2.3 type17 and added type2) on XP, Windows7, and Linux, and all of them seemed happy and none of them seemed to mind... Just sayin' ;)
Thanks for running tests. One thing that has bitten us in the past is OSes re-running license checks and/or popping up "new hardware" notifications on bios table changes.
-Kevin