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