Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)

[Laszlo Ersek <lersek@redhat.com>]

On 03/31/14 22:18, Gabriel L. Somlo wrote:
> On Wed, Mar 26, 2014 at 06:36:10PM -0400, Kevin O'Connor wrote:
>> On Wed, Mar 26, 2014 at 03:58:50PM -0400, Gabriel L. Somlo wrote:
>>> - SeaBIOS is still in charge of providing the smbios_entry_point
>>>   structure, and it's unlikely we can reasonably expect it to
>>>   bump the version to 2.5 (not that it seems to matter, if my
>>>   tests are to be believed)
>>
>> This is why ultimately we want to use the romfile_loader mechanism for
>> smbios - that interface will allow qemu to generate both the smbios
>> table and the smbios entry point.
> 
> Ah, so romfile_loader is the "whole-blob" fw_cfg transfer method (so
> far in smbios.c we've been dealing with individual fields, and
> individual table types).
> 
> The only sticking point remaining would be who gets to generate the
> Type 0 (BIOS Information) table and when, which is something QEMU
> should arguably NOT be doing on behalf of SeaBIOS (or OVMF, or ...).
> 
> I guess everyone's busy with QEMU 2.0, so I'll keep playing with this
> stuff on my own and bring it up again afterwards.
> 
> Obviously, more comments and feedback are welcome at any time, should
> there be any interest :)

Sorry I can follow this discussion only intermittently.

- I think OVMF would be fine with the Type 0 table as-is (it has a
default table and adheres to field-level patches). Full tables for other
types would be welcome.

- In edk2 (and on platforms that conform to the platform init (PI)
spec), platform drivers install their smbios tables through
EFI_SMBIOS_PROTOCOL. (Documented in Vol5 of the PI spec.)

In edk2, the "central" driver that produces this protocol (== provides
the service) is "MdeModulePkg/Universal/SmbiosDxe".

The OVMF platform driver that installs the smbios tables through the
protocol (== consumes the service) is "OvmfPkg/SmbiosPlatformDxe".

The set and the contents of the smbios tables are the jurisdiction of
the platform driver (the service consumer) -- the driver in OvmfPkg.

The smbios entry point (including the smbios std version) is the
jurisdiction of the service producer -- the driver in MdeModulePkg.

The platform driver can query the smbios std version from
EFI_SMBIOS_PROTOCOL. The platform driver should also filter the tables
it intends to install through the protocol so that the table types
conform to the smbios std version supported by the service provider.

This is to say, OVMF can fetch tables via fw_cfg, and install them via
the EFI_SMBIOS_PROTOCOL instance that "MdeModulePkg/Universal/SmbiosDxe"
provides. However, OVMF can't change the SMBIOS version or other aspects
of the smbios entry point. At best OVMF could filter out tables (grabbed
from fw_cfg) that are above the std version that EFI_SMBIOS_PROTOCOL
supports/advertises.

Currently OVMF does no such filtering (it would require hard-coding
which table type is defined in which smbios version). It does require
support for version 2.3, or it gives up.

In any case, the SMBIOS version currently supported by
"MdeModulePkg/Universal/SmbiosDxe" is 2.7.1 (SVN r11690), which is quite
permissive.

Summary:
- type 0 should be OK as-is, other types are most welcome as full blobs,
- OvmfPkg can't influence the smbios version advertised, it belongs to
qanother (central) driver in edk2 that is built into OVMF.fd,
- OvmfPkg currently doesn't filter fw_cfg table types against the smbios
version (determined by that other, central driver in edk2),
- however that version is reasonably high (2.7.1).

(Note: most of "OvmfPkg/SmbiosPlatformDxe" that's relevant for the above
is not in upstream edk2. You can find the patches in
<http://www.kraxel.org/repos/manual/edk2/> and
<http://copr-be.cloud.fedoraproject.org/results/bonzini/ovmf/>.)

Thanks
Laszlo