Re: [Qemu-devel] [QEMU v5 PATCH 00/18] SMBIOS: build full tables in QEMU

[Laszlo Ersek]

On 04/13/14 02:55, Gabriel L. Somlo wrote:
> 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 ?

You're moving too fast for me. I'm swamped. By the time I'd come around
reading and *maybe* answering your email, you make so much progress that
you send three others :)

So, I'll defer to y'all's good judgement.

(I don't let my sense of taste get in my way any longer (and actually I
don't want *others'* taste get in my way either, for that matter, when
I'm the one posting patches...), so just make something simple and
bug-free, document the format, and I'll adapt.)

Thanks!
Laszlo