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
|
2015-02-02 20:08:57 +01:00
|
|
|
QemuFwCfgAcpi.c
|
2012-05-31 01:15:27 +02:00
|
|
|
Xen.c
|
2015-02-20 00:45:57 +01:00
|
|
|
EntryPoint.c
|
2016-03-13 15:34:07 +01:00
|
|
|
PciDecoding.c
|
2017-02-09 17:32:40 +01:00
|
|
|
BootScript.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
|
2017-02-22 03:47:18 +01:00
|
|
|
QemuFwCfgS3Lib
|
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
|
2016-03-13 15:34:07 +01:00
|
|
|
gEfiPciIoProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
|
2012-05-31 01:15:00 +02:00
|
|
|
|
2012-05-31 01:15:27 +02:00
|
|
|
[Guids]
|
|
|
|
|
gEfiXenInfoGuid
|
2016-03-13 18:09:57 +01:00
|
|
|
gRootBridgesConnectedEventGroupGuid
|
2012-05-31 01:15:27 +02:00
|
|
|
|
2012-05-31 01:15:00 +02:00
|
|
|
[Pcd]
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
|
OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration dynamic
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should have been
downloaded only after PCI enumeration. Said commit implemented the
dependency by tightening the module's depex.
This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
matching protocol registration callback. The depex was static, and it
could not handle dynamically discovered situations when the dependency
would turn out invalid.
Namely:
- At the moment, the depex in "QemuFwCfgAcpiPlatformDxe.inf" assumes
that "ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc"
lacks PCI support. However, PCI support is about to become run-time
discoverable on that platform. If PCI support is missing, then
ArmVirtualizationPkg will set PcdPciDisableBusEnumeration to TRUE.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
- InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets
PcdPciDisableBusEnumeration to TRUE. This causes
PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c"
to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
"MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to
PciEnumeratorLight(). The installation of
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is
not reached.
Which means that starting with SVN r16411, AcpiPlatformDxe is never
dispatched on Xen.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: Removed PcdOvmfPciEnabled]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16887 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-20 00:46:27 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
|
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 dynamic
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should have been
downloaded only after PCI enumeration. Said commit implemented the
dependency by tightening the module's depex.
This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
matching protocol registration callback. The depex was static, and it
could not handle dynamically discovered situations when the dependency
would turn out invalid.
Namely:
- At the moment, the depex in "QemuFwCfgAcpiPlatformDxe.inf" assumes
that "ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc"
lacks PCI support. However, PCI support is about to become run-time
discoverable on that platform. If PCI support is missing, then
ArmVirtualizationPkg will set PcdPciDisableBusEnumeration to TRUE.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
- InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets
PcdPciDisableBusEnumeration to TRUE. This causes
PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c"
to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
"MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to
PciEnumeratorLight(). The installation of
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is
not reached.
Which means that starting with SVN r16411, AcpiPlatformDxe is never
dispatched on Xen.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: Removed PcdOvmfPciEnabled]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16887 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-20 00:46:27 +01:00
|
|
|
gEfiAcpiTableProtocolGuid
|
