[SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

[Laszlo Ersek]

On 06/10/13 21:57, Anthony Liguori wrote:
> Laszlo Ersek <lersek at 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