qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS v3 PATCH] SMBIOS: Check for full tables & entr


From: Markus Armbruster
Subject: Re: [Qemu-devel] [SeaBIOS v3 PATCH] SMBIOS: Check for full tables & entry point in fw_cfg
Date: Tue, 15 Apr 2014 10:36:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

"Gabriel L. Somlo" <address@hidden> writes:

> Check fw_cfg for the presence of a complete set of smbios
> tables (etc/smbios/smbios-tables) and an entry point structure
> (etc/smbios/smbios-anchor), and, if found, use them instead of
> generating our own copies locally.
>
> We ensure the presence of a type 0 (bios information) structure
> by generating one locally if necessary, which is expected to be
> the common case.
>
> Signed-off-by: Gabriel L. Somlo <address@hidden>
> ---
>
> This now goes on top of Kevin's patch factoring out smbios table walking
> into smbios_next().
>
> On Sat, Apr 12, 2014 at 11:56:08AM -0400, Kevin O'Connor wrote:
>> I'd prefer to add this code to src/fw/paravirt.c and
>> src/fw/biostables.c instead of src/fw/smbios.c.  That way, the
>> smbios.c file is limited to the legacy smbios generation and we can
>> more clearly document that the whole file is deprecated.
>
> OK, so most of the new code is now in biostables.c, hope that's OK.
>
>> 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").
>
> Something like that, except (hopefully) even simpler :)
>
> If QEMU adds its (still optional) type 0 structure, SeaBIOS just uses
> everything as-is. If no type 0 structure is found, we generate and
> prepend our own, and update the entry point fields accordingly.
>
> I expect the latter to be the common case (having QEMU add its own
> type 0 sub-table is rare, and discouraged in practice, according to
> the QEMU guys).

Messing with SMBIOS entries is a rather obscure feature, and messing
with type 0 is perhaps more obscure than messing with type 1.

QEMU provides two ways to mess with SMBIOS entries:

* -smbios type=T,KEY=VAL...

  T can be either 0 or 1.

* -smbios file=F

  F contains an SMBIOS struct.  Its type is parsed from file F.

If -smbios file=F is given, it completely defines the type T entry.
Else, the type T entry is to be constructed from SeaBIOS defaults and
any -smbios type=T,... given.

If I read your discussion correctly, you're proposing to change "from
SeaBIOS defaults" to "from QEMU defaults".  Correct?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]