"Gabriel L. Somlo" <gso...@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:
>
> 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).
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 :)
> 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).
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.
