"Gabriel L. Somlo" gsomlo@gmail.com writes:
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:
- 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).
Begs the question how QEMU would figure out what exactly the BIOS wants it to put into the type 0 table. Unless somebody can come up with a practical answer, we can ignore this option :)
- 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 :)
- 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).
This is a simplification of 2: the BIOS doesn't have to check whether QEMU provided type 0 information. Paid for with an incompatible change of a somewhat obscure QEMU feature.
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 ?
My unsolicited advice: if 2. is easy for you, go for it.