Kevin,
Thanks for the comments. I'll work your feedback (and any other
feedback I get by early next week) into another iteration of smbios
patches for both SeaBIOS and QEMU.
In the mean time, there's one remaining "big picture" design question:
On Sat, Apr 12, 2014 at 11:56:08AM -0400, Kevin O'Connor wrote:
> QEMU currently has command-line options that can modify the fields of
> the type0 tables (-smbios type=0,vendor='foo'). To continue to
> support that, I think QEMU should be able to build the type0 table as
> it feels fit to, and SeaBIOS should be able to pass it through. Of
> course, if there's no specific request from the end user, then I think
> QEMU can tell SeaBIOS that it may replace the type0 content with its
> own data (eg, via "etc/update-smbios-type0").
>
> [...]
>
> As a minor quibble, I think patch 18 should make type0 required
> instead of optional (once there are the new fw_cfg entries there is no
> harm in always producing type0). Also, it would be nice to move up
> patch 18 to after patch 10 - that way an end-to-end test between
> old/new smbios with the new interface could be done. I defer to
> regular qemu developers on these comments though.
There's three options I can think of:
1. QEMU always generates its own type 0 table. In this case, SeaBIOS
can probably just use that, along with the rest of the tables, as
provided. QEMU would have to "impersonate" or "channel" SeaBIOS when
generating the type 0 table (or "channel" TianoCore, depending on which
bios is being used).
2. QEMU only generates type 0 if explicitly told to do so on the
command line (i.e., *not* by default). In this case, SeaBIOS (or OVMF,
or any other BIOS) would have to scan the tables and insert its own
default type 0 if one was not purposely supplied by QEMU. (I know my
current SeaBIOS patch always overrides type 0, and agree that's
inconsistent with this option, and plan on fixing it :)
3. QEMU never generates a type 0 structure (i.e. we remove that
command line option), and the BIOS is *always* responsible for
generating it ("allowing type 0 on the qemu command line was a bad
idea, nobody uses it, we shouldn't have done it in the first place",
to paraphrase from an earlier thread).
I personally like #2 as it appears simple and flexible, and doesn't
require any further coordination (beyond qemu providing an entry
point and a set of tables).
However, I'm not religious about it -- I'm only really after type 2
and 17, for OS X's sake, as you all may remember... :)
Gerd, Laszlo, what do you guys think ?
Thanks,
--Gabriel
