On 06/10/13 21:57, Anthony Liguori wrote:
Laszlo Ersek lersek@redhat.com writes:
Please take a look at my series for OVMF that adds basic support for SMBIOS tables. It took me three days of basically uninterrupted coding and two approaches to throw away until I got something submittable (with default tables for only type 0 and type 1).
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3037
I don't want to invite accusations like "this is a strawman argument, noone was speaking about SMBIOS", but the selective, dynamic patching is somewhat similar between AML and SMBIOS in any given boot firmware. You got a big bunch of named offsets that must be mangled individually.
Allowing the firmware to only install blobs verbatim, or maybe patch them but only in a completely programmatic manner (ie. without specific field names & offsets in the firmware, which I did try for SMBIOS in OVMF, and failed, (*)), would be a big help.
((*) because the fw_cfg format of individual SMBIOS fields doesn't distinguish formatted fields from strings in the unformatted area)
I don't understand this piece.
Other than TianoCore being a weird environment, what made this more difficult than it is to generate the tables in QEMU?
QEMU can pass down two kinds of SMBIOS config items over fw_cfg: verbatim tables and individual fields.
The verbatim table kind means "install this table as-is". I'm not sure how SeaBIOS solves it, in OVMF you call Smbios->Add().
Regarding the "field kind" config item: for each table type required by the SMBIOS spec, if qemu doesn't provide such a table in whole / in verbatim, then the firmware must install a default table for that type, *and* patch it with any referring field kind config items.
Given the current format of the "field kind" config item, it is currently not possible to just iterate over the "field kind" config items, and patch whatever field in whatever table they refer to. The information contained in the "field kind" config item is insufficient to do this.
The "field kind" config item designates a (table, field offset) pair. If that offset points at a string-typed SMBIOS field (basically string serial number into the unformatted area), one must update the unformatted string area after the actual table fields. (In OVMF one does this with a different call, Smbios->UpdateStrings(), and at that point the table even must have been installed already.)
If the offset points at a non-string-typed (= in-formatted-area) field, the field must be overwritten in-place. (In OVMF this must happen *before* table installation, ie. before Smbios->Add().)
So, the current fw_cfg representation is insufficient, and the firmware must extend (or qemu should have extended) the info contents with this distinction between formatted and unformatted. Again this differs from field to field and the origin of that classification is the SMBIOS spec.
Until this point in my email there has been no clear indication whether qemu or the firmware should do this. *Some* side will have to suffer shoveling the field/offset info, and a table template for each type, from the SMBIOS spec into code. I described the above solely as background, to set the landscape.
(a) The first thing that tips the scale is: of qemu there is one, and of firmware, there exist at least two, *wildly different* implementations. (Apologies, I forgot about coreboot; not sure if it's affected.) It's not a design purity argument, just what's cheaper.
(b) The second thing that further unbalances the scale: suppose you decide to add further field-kind overrides to qemu. For example, currently Type 3 (chassis information, table required by SMBIOS spec) cannot be overridden field-wise.
If a user is unhappy with her firmware's default Type 3 table, she's allowed to hex-edit a Type 3 blob, and pass it with "-smbios file=type3.blob" on the qemu command line. If you as developer want to provide her with more flexibility, you need to (i) patch qemu (of course), to recognize individual fields on the command line, and to populate fw_cfg with them, (ii) patch *every single firmware* supported by qemu to *look for* those (type=3,offset) field-kind config entries, and to effectuate them.
If you pass down only verbatim tables, then (ii) falls away. You don't have to update SeaBIOS, nor OVMF. As a bonus, you don't have to care about versions: age-old firmware that only knows how to install verbatim tables will immediately benefit from qemu's new-fangled Type 3 flexibility.
Case in point: https://bugzilla.redhat.com/show_bug.cgi?id=788142. (Non-public bug, sorry about that. I think I can disclose that it is about supporting the "field kind" config entry for Type 3 tables.)
For ACPI tables, especially for tables containing AML, multiply the cost of (ii) by twenty. Many more offsets to patch and vastly more dependencies via fw_cfg.
Laszlo