summaryrefslogtreecommitdiff
path: root/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2014-09-22 21:11:22 +0000
committerlersek <lersek@6f19259b-4bc3-4df7-8a09-765794883524>2014-09-22 21:11:22 +0000
commit387536e472aa0eb4a169f8456167fef53524fbe0 (patch)
treebaf1c6c6030764dd3b22751787836f4c827a6c14 /OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
parent56947bc0810a8b85e9cb7fa7fd6ea23a7276bf7b (diff)
OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface
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 order to stay compatible with EFI_ACPI_TABLE_PROTOCOL, we don't try to identify QEMU's RSD PTR and link it into the UEFI system configuration table. Instead, once all linker/loader commands have been processed, we process the AddPointer commands for a second time. In the second pass, we look at the targets of these pointer commands. The key idea (by Michael Tsirkin) is that any ACPI interpreter will only be able to locate ACPI tables by following absolute pointers, hence QEMU's set of AddPointer commands will cover all of the ACPI tables (and more, see below). Some of QEMU's AddPointer commands (ie. some fields in ACPI tables) may point to areas in fw_cfg blobs that are not ACPI tables themselves. Examples are the BGRT.ImageAddress field, and the TCPA.LASA field. We tell these apart from ACPI tables by performing the following checks on pointer target "candidates": - length check against minimum ACPI table size, and remaining blob size - checksum verification. If a target area looks like an ACPI table, and is different from RSDT and DSDT (which EFI_ACPI_TABLE_PROTOCOL handles internally), we install the table (at which point EFI_ACPI_TABLE_PROTOCOL creates a deep copy of the relevant segment of the pointed-to fw_cfg blob). Simultaneously, we keep account if each fw_cfg blob has ever been referenced as the target of an AddPointer command without that AddPointer command actually identifying an ACPI table. In this case the containing fw_cfg file (of AcpiNVS memory type) must remain around forever, because we never install that area with EFI_ACPI_TABLE_PROTOCOL, but some field in some ACPI table that we *do* install still references it, by the absolute address that we've established during the first pass. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16158 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf')
-rw-r--r--OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf1
1 files changed, 1 insertions, 0 deletions
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 90178e0f52..3229d71cc7 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -51,6 +51,7 @@
MemoryAllocationLib
BaseLib
DxeServicesTableLib
+ OrderedCollectionLib
[Protocols]
gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED