summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2014-11-20 09:58:28 +0000
committerlersek <lersek@Edk2>2014-11-20 09:58:28 +0000
commit66b280df282ae82888d2eb416bfeda3f65afa386 (patch)
tree3a557baf0df0e8231ba874bf6198fd24a1d72397 /OvmfPkg
parentbab9f949bf1a72f33f89331bbffa9362de254945 (diff)
downloadedk2-66b280df282ae82888d2eb416bfeda3f65afa386.tar.gz
edk2-66b280df282ae82888d2eb416bfeda3f65afa386.tar.bz2
edk2-66b280df282ae82888d2eb416bfeda3f65afa386.zip
OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicit
The ACPI payload that OVMF downloads from QEMU via fw_cfg depends on the PCI enumaration and resource assignment performed by MdeModulePkg/Bus/Pci/PciBusDxe. Namely, although the ACPI payload is pre-generated in qemu during machine initialization, in main() [vl.c] qemu_run_machine_init_done_notifiers() pc_guest_info_machine_done() [hw/i386/pc.c] acpi_setup() [hw/i386/acpi-build.c] acpi_build() acpi_add_rom_blob() rom_add_blob(... acpi_build_update ...) [hw/core/loader.c] fw_cfg_add_file_callback() [hw/nvram/fw_cfg.c] the ACPI data is rebuilt at the first time any of the related fw_cfg files are read, through the acpi_build_update() fw_cfg read-callback function: fw_cfg_read() [hw/nvram/fw_cfg.c] acpi_build_update() [hw/i386/acpi-build.c] acpi_build() (See qemu commit d87072ceeccf4f84a64d4bc59124bcd64286c070 and its containing series.) For this reason we must not dispatch AcpiPlatformDxe before PciBusDxe completes the enumeration. Luckily, the PI Specification 1.3 defines EFI_PCI_ENUMERATION_COMPLETE_GUID in Volume 5, "10.9 End of PCI Enumeration Overview", as an indicia to inform the platform when the PCI enumeration process has completed. PciBusDxe installs this protocol at the end of the PciEnumerator() function. Let's add this GUID to the Depex section of AcpiPlatformDxe, in order to state the dependency explicitly. On Xen, and on older QEMU where the linker/loader fw_cfg interface is unavailable, this introduces a harmless ordering constraint -- we'll always include PciBusDxe in OVMF, so the dependency will always be satisfied. I tested this change as follows: - I dumped the ACPI tables in a Fedora 20 guest, before and after the change, and compared them. The only thing that actually changed was the FACS address. (Which I promptly tested with S3 suspend/resume.) Plus, of course, the FACP checksum changed, because the FACP links the FACS. - Tested S3 in my Windows Server 2008 R2 and Windows Server 2012 R2 guests. 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@16411 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'OvmfPkg')
-rw-r--r--OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf2
1 files changed, 1 insertions, 1 deletions
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 3229d71cc7..c6dced21c1 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -66,5 +66,5 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
[Depex]
- gEfiAcpiTableProtocolGuid
+ gEfiAcpiTableProtocolGuid AND gEfiPciEnumerationCompleteProtocolGuid