On 08/26/14 00:24, Jordan Justen wrote:
> On Fri, Aug 8, 2014 at 7:08 PM, Laszlo Ersek <[email protected]> wrote:
>> Recent changes in the QEMU ACPI table generator have shown that our
>> limited client for that interface is insufficient and/or brittle.
>>
>> Implement the full interface utilizing OrderedCollectionLib for addressing
>> fw_cfg blobs by name.
>>
>> In addition, we stop using EFI_ACPI_TABLE_PROTOCOL in the QEMU loader
>> client, because:
>> - splitting the blobs for EFI_ACPI_TABLE_PROTOCOL is just untenable short
>> of a complete ACPI parser,
>> - and it is fully sufficient to install the RSD PTR as an EFI
>> configuration table for the guest OS to see everything.
>>
>> In short, for this interface, EFI_ACPI_TABLE_PROTOCOL is an unwanted and
>> restrictive convenience; let's stop using it.
>
> Hmm. Been through a few rounds of this for Xen. It's QEMU's turn now? :)
>
> Is this required?
Depends on how good (how accurate) ACPI tables you want to have in your
VMs. For a few qemu releases now, qemu has been the "master" of ACPI
payload generation. SeaBIOS too has kept its own builtin tables, yes,
but when the QEMU generated payload is available, it interprets this
linker/loader script just the same.
If you want PCI hotplug, pvpanic support; or, going forward, memory
hotplug, then yes, those things need ACPI support, and the ACPI stuff
for them is now developed in QEMU (and dynamically generated by it,
dependent on the actual hardware config).
> What happens if another driver uses EFI_ACPI_TABLE_PROTOCOL? We now
> have two drivers that want to install the pointer.
Yes, I checked that. The UEFI spec says that whenever you install a
configuration table that's already present (by GUID), the reference is
updated.
InstallConfigurationTable()
[...]
* If Guid is present in the System Table, and Table is not NULL, then
the (Guid, Table) pair is updated with the new Table value.
[...]
For this reason, the first thing InstallAllQemuLinkedTables() does is
check, with EfiGetSystemConfigurationTable(), for the presence of any of
the ACPI GUIDs in the config table.
There's no "absolute" cure against another driver in OVMF just grabbing
EFI_ACPI_TABLE_PROTOCOL and installing its own stuff (which would then
completely hide the tables installed by this patchset, because
"MdeModulePkg/Universal/Acpi/AcpiTableDxe" would simply replace QEMU's
RSD PTR's address in the UEFI config table with its own).
But ACPI tables are not randomly installed in OVMF, we keep it
centralized in AcpiTableDxe.
> It seems the AcpiTableDxe driver has had to fix things on occasion to
> cover some corner cases of table publishing. Did you capture all
> these? What about future bugs?
The point of this series, and more importantly, qemu's linker/loader
interface, is that the firmware can remain dumb. It doesn't need to know
about inter-table relationships, it doesn't need to know about tables.
It only needs to recognize the RSD PTR (which we can easily do now, in a
way that was suggested by Michael).
Bugs in ACPI payload, including inter-table relationships, will now be
caused by QEMU, and will have to be fixed in QEMU; they can remain
transparent to OVMF.
> How did Xen manage to end up using EFI_ACPI_TABLE_PROTOCOL if it is
> not possible or practical for QEMU?
>
> What is it about EFI_ACPI_TABLE_PROTOCOL that is such a bad fit for VMs?
The difference is simply in how the different hypervisors provide the
ACPI stuff to the firmware. Xen elected for a per-table export, which
OVMF can super-easily pass to EFI_ACPI_TABLE_PROTOCOL, because the
latter expects individual tables as well.
QEMU chose a different path. The interface does not expose ACPI tables
as such, it exposes blobs that may contain binary data that, once
correctly cross-linked and checksummed, will be understood by a
full-blown ACPI interpreter (the ones you can find in OS kernels). This
is *very* convenient for SeaBIOS.
We tried to split the blobs into individual tables before, so that we
could pass each table to EFI_ACPI_TABLE_PROTOCOL individually.
This splitting logic turned out to be brittle. Although there wasn't
(and still isn't) any semi-official, written contract for the
linker/loader interface, our splitting logic did not meet the *intent*
of the qemu interface; it abused it.
And, in practice, please see this recent qemu-devel discussion -- an
example where our current, splitter approach would break down. It's
about TPM / TCPA.
http://thread.gmane.org/gmane.comp.emulators.qemu/287985
This thread was what finally convinced me that I'd have to implement the
full thing.
BTW you don't have to look at Xen for a per-table approach. If you check
QEMU's new SMBIOS (as opposed to ACPI) generator (for which Gabriel has
contributed the OVMF client code too), that's table-based as well, and
uses EFI_SMBIOS_PROTOCOL.
Now, if you want to know why the QEMU ACPI interface was *designed* like
this, ie. with such a mismatch for EFI_ACPI_TABLE_PROTOCOL, I'm
partially to blame for that.
First, I was unusually overloaded at that time.
Second, moving the ACPI generator from SeaBIOS to QEMU was like a small
civil war in the qemu developer community. By the time this conflict
progressed to a phase where actual, technical specifics were possible to
discuss, the social traits of that discussion had made me want to have
nothing to do with it. As a thin-skinned person I was incapable of
collaborating on the design, and provide hints about UEFI compatibility
in a timely manner. Ultimately, the interface was specialized for the
QEMU and SeaBIOS, and largely ignored OVMF.
TL;DR: I should have insisted on an interface that would match
EFI_ACPI_TABLE_PROTOCOL better, but I had very little time, plus I could
not bear participating in that ACPI debate and the later design. I
failed to "steer" the design closer to OVMF. Sorry.
Laszlo
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
