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
