On 08/26/14 02:12, Jordan Justen wrote: > 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?
No. It's not a good idea. But if we want to support the qemu interface, in the manner that interface has been intended, then I can see no way around avoiding EFI_ACPI_TABLE_PROTOCOL. The only way you could reliably fish out tables, operation regions etc. from the qemu payload would be to write a near-full ACPI interpreter. The goal of the interface is the polar opposite, ie. to require the firmware to know the least possible about ACPI table specifics. > What about MdeModulePkg/Universal/Network/IScsiDxe/IScsiIbft.c, which > uses EFI_ACPI_TABLE_PROTOCOL? Good find. > Do we need to keep monitoring which EDK II drivers decide to use > EFI_ACPI_TABLE_PROTOCOL, I guess so. > or can we find a way to make these work > together? I doubt it. The current in-tree solution is probably as good as it gets with EFI_ACPI_TABLE_PROTOCOL. It would co-operate with IScsiIbft.c, but (if you read the TPM thread I linked from qemu-devel) it would install a broken TCPA table from QEMU, for example. > If the answer is no, then I wonder if this is something that > UEFI or EDK II needs to consider. Maybe it is. As far as the UEFI spec goes, EFI_ACPI_TABLE_PROTOCOL looks like the canonical way. RSD PTR being referenced in the config table is not even part of the UEFI spec (if I searched it right); it's described in the ACPI spec. The UEFI spec only names the relevant GUIDs, but doesn't explain how to use them. In any case, under the IBFT example you name, we have a conflict because ACPI tables have two genuine, distinct sources. IBFT comes from the firmware, while the rest would come from QEMU. (I don't know if IBFT could be provided by QEMU. The ACPI 5.1 spec doesn't describe the table. Googling led me to a license acceptance window at Microsoft's site, which I closed.) In practice, IBFT seems less important than the tables that QEMU does offer -- embedded in blobs -- eg. I forgot to mention VCPU hotplug. Thanks, 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
