On Mon, Aug 25, 2014 at 4:27 PM, Laszlo Ersek <[email protected]> wrote: > 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.
I don't agree with this statement. Rather, I would say that OVMF follows the EDK II method of publishing tables, which means EFI_ACPI_TABLE_PROTOCOL. In the past we were a good little sample platform, and provided the ACPI tables directly. Well, that is less and less the case. But, is it a good idea to stop using EFI_ACPI_TABLE_PROTOCOL? What about MdeModulePkg/Universal/Network/IScsiDxe/IScsiIbft.c, which uses EFI_ACPI_TABLE_PROTOCOL? Do we need to keep monitoring which EDK II drivers decide to use EFI_ACPI_TABLE_PROTOCOL, or can we find a way to make these work together? If the answer is no, then I wonder if this is something that UEFI or EDK II needs to consider. -Jordan >> 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 ------------------------------------------------------------------------------ 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
