2012-05-31 01:15:00 +02:00
|
|
|
## @file
|
2012-05-31 01:15:27 +02:00
|
|
|
# OVMF ACPI Platform Driver
|
2012-05-31 01:15:00 +02:00
|
|
|
#
|
2012-05-31 01:15:27 +02:00
|
|
|
# Copyright (c) 2008 - 2012, Intel Corporation. All rights reserved.<BR>
|
2012-05-31 01:15:00 +02:00
|
|
|
# This program and the accompanying materials
|
|
|
|
|
# are licensed and made available under the terms and conditions of the BSD License
|
|
|
|
|
# which accompanies this distribution. The full text of the license may be found at
|
|
|
|
|
# http://opensource.org/licenses/bsd-license.php
|
2012-05-31 01:15:27 +02:00
|
|
|
#
|
2012-05-31 01:15:00 +02:00
|
|
|
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
|
|
|
|
|
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
|
2012-05-31 01:15:27 +02:00
|
|
|
#
|
2012-05-31 01:15:00 +02:00
|
|
|
##
|
|
|
|
|
|
|
|
|
|
[Defines]
|
|
|
|
|
INF_VERSION = 0x00010005
|
|
|
|
|
BASE_NAME = AcpiPlatform
|
2012-06-07 05:21:17 +02:00
|
|
|
FILE_GUID = 49970331-E3FA-4637-9ABC-3B7868676970
|
2012-05-31 01:15:00 +02:00
|
|
|
MODULE_TYPE = DXE_DRIVER
|
|
|
|
|
VERSION_STRING = 1.0
|
|
|
|
|
ENTRY_POINT = AcpiPlatformEntryPoint
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# The following information is for reference only and not required by the build tools.
|
|
|
|
|
#
|
|
|
|
|
# VALID_ARCHITECTURES = IA32 X64 IPF EBC
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
[Sources]
|
|
|
|
|
AcpiPlatform.c
|
2012-05-31 01:15:27 +02:00
|
|
|
Qemu.c
|
|
|
|
|
Xen.c
|
2012-05-31 01:15:00 +02:00
|
|
|
|
|
|
|
|
[Packages]
|
|
|
|
|
MdePkg/MdePkg.dec
|
|
|
|
|
MdeModulePkg/MdeModulePkg.dec
|
2012-05-31 01:15:27 +02:00
|
|
|
OvmfPkg/OvmfPkg.dec
|
2012-08-13 17:42:07 +02:00
|
|
|
UefiCpuPkg/UefiCpuPkg.dec
|
|
|
|
|
PcAtChipsetPkg/PcAtChipsetPkg.dec
|
2012-05-31 01:15:00 +02:00
|
|
|
|
|
|
|
|
[LibraryClasses]
|
|
|
|
|
UefiLib
|
|
|
|
|
DxeServicesLib
|
|
|
|
|
PcdLib
|
|
|
|
|
BaseMemoryLib
|
|
|
|
|
DebugLib
|
|
|
|
|
UefiBootServicesTableLib
|
|
|
|
|
UefiDriverEntryPoint
|
2012-05-31 01:15:27 +02:00
|
|
|
HobLib
|
|
|
|
|
QemuFwCfgLib
|
2012-05-31 01:15:59 +02:00
|
|
|
MemoryAllocationLib
|
2012-07-19 00:33:48 +02:00
|
|
|
BaseLib
|
2012-07-31 20:18:01 +02:00
|
|
|
DxeServicesTableLib
|
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
2014-09-22 23:11:22 +02:00
|
|
|
OrderedCollectionLib
|
2012-05-31 01:15:00 +02:00
|
|
|
|
|
|
|
|
[Protocols]
|
|
|
|
|
gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
|
|
|
|
|
|
2012-05-31 01:15:27 +02:00
|
|
|
[Guids]
|
|
|
|
|
gEfiXenInfoGuid
|
|
|
|
|
|
2012-05-31 01:15:00 +02:00
|
|
|
[Pcd]
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
|
2012-08-13 17:42:07 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
|
|
|
|
|
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
|
2013-11-12 19:34:36 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
|
2012-05-31 01:15:00 +02:00
|
|
|
|
|
|
|
|
[Depex]
|
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
2014-11-20 10:58:28 +01:00
|
|
|
gEfiAcpiTableProtocolGuid AND gEfiPciEnumerationCompleteProtocolGuid
|
2012-05-31 01:15:00 +02:00
|
|
|
|
