audk/OvmfPkg/OvmfPkgIa32.dsc

872 lines
39 KiB
Plaintext
Raw Normal View History

## @file
# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
#
# Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
OvmfPkg: use StatusCode Router and Handler from MdeModulePkg In the Platform Init v1.4a spec, - Volume 1 "4.7 Status Code Service" defines the EFI_PEI_SERVICES.ReportStatusCode() service, - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), - Volume 2 "14.2 Status Code Runtime Protocol" defines the EFI_STATUS_CODE_PROTOCOL. These allow PEIMs and DXE (and later) modules to report status codes. Currently OvmfPkg uses modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above abstractions (PPI and PROTOCOL) directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. In the Platform Init v1.4a spec, - Volume 3 "7.2.2 Report Status Code Handler PPI" defines EFI_PEI_RSC_HANDLER_PPI, - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines EFI_RSC_HANDLER_PROTOCOL. These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com> Suggested-by: Liming Gao <liming.gao@intel.com> Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63 [jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-08-02 19:25:10 +02:00
# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
#
# 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
#
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
#
##
################################################################################
#
# Defines Section - statements that will be processed to create a Makefile.
#
################################################################################
[Defines]
PLATFORM_NAME = Ovmf
PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b
PLATFORM_VERSION = 0.1
DSC_SPECIFICATION = 0x00010005
OUTPUT_DIRECTORY = Build/OvmfIa32
SUPPORTED_ARCHITECTURES = IA32
BUILD_TARGETS = NOOPT|DEBUG|RELEASE
SKUID_IDENTIFIER = DEFAULT
FLASH_DEFINITION = OvmfPkg/OvmfPkgIa32.fdf
#
# Defines for default states. These can be changed on the command line.
# -D FLAG=VALUE
#
DEFINE SECURE_BOOT_ENABLE = FALSE
DEFINE NETWORK_IP6_ENABLE = FALSE
DEFINE HTTP_BOOT_ENABLE = FALSE
DEFINE SMM_REQUIRE = FALSE
DEFINE TLS_ENABLE = FALSE
#
# Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
# one of the supported values, in place of any of the convenience macros, is
# permitted.
#
!ifdef $(FD_SIZE_1MB)
DEFINE FD_SIZE_IN_KB = 1024
!else
!ifdef $(FD_SIZE_2MB)
DEFINE FD_SIZE_IN_KB = 2048
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-04-29 03:37:41 +02:00
!else
!ifdef $(FD_SIZE_4MB)
DEFINE FD_SIZE_IN_KB = 4096
!else
DEFINE FD_SIZE_IN_KB = 4096
!endif
!endif
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-04-29 03:37:41 +02:00
!endif
[BuildOptions]
GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
MSFT:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
GCC:*_*_*_CC_FLAGS = -mno-mmx -mno-sse
#
# Disable deprecated APIs.
#
MSFT:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
INTEL:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
# Force PE/COFF sections to be aligned at 4KB boundaries to support page level
# protection of DXE_SMM_DRIVER/SMM_CORE modules
[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
XCODE:*_*_*_DLINK_FLAGS =
################################################################################
#
# SKU Identification section - list of all SKU IDs supported by this Platform.
#
################################################################################
[SkuIds]
0|DEFAULT
################################################################################
#
# Library Class section - list of all Library Classes needed by this Platform.
#
################################################################################
[LibraryClasses]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
PciCf8Lib|MdePkg/Library/BasePciCf8Lib/BasePciCf8Lib.inf
PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf
PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
DevicePathLib|MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf
NvVarsFileLib|OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib.inf
MdeModulePkg, MdePkg, NetworkPkg, OvmfPkg, PerformancePkg, ShellPkg: Library Migration. Move libraries from ShellPkg into MdeModulePkg and MdePkg. The following libraries are being migrated out of ShellPkg in order to make their functionality more widely available. • PathLib: Incorporate into MdePkg/Library/BaseLib • FileHandleLib: MdePkg/Library/UefiFileHandleLib • BaseSortLib: MdeModulePkg/Library/BaseSortLib • UefiSortLib: MdeModulePkg/Library/UefiSortLib Diffs showing file changes are in the attached file, LibMigration.patch. A description of the changes follows: • Move ShellPkg/Include/Library/FileHandleLib.h to MdePkg/Include/Library/FileHandleLib.h • Move ShellPkg/Include/Library/SortLib.h to MdeModulePkg/Include/Library/SortLib.h • Move ShellPkg/Library/BaseSortLib to MdeModulePkg/Library/BaseSortLib • Move ShellPkg/Library/UefiSortLib to MdeModulePkg/Library/UefiSortLib • Move ShellPkg/Library/BasePathLib/BasePathLib.c to MdePkg/Library/BaseLib/FilePaths.c • Merge ShellPkg/Include/Library/PathLib.h into MdePkg/Include/Library/BaseLib.h • Delete ShellPkg/Library/BasePathLib; Includes BasePathLib.c and BasePathLib.inf • NetworkPkg/NetworkPkg.dsc • PerformancePkg.dsc • OvmfPkg/OvmfPkgX64.dsc • OvmfPkg/OvmfPkgIa32X64.dsc • OvmfPkg/OvmfPkgIa32.dsc o Update SortLib and FileHandleLib library classes to point to the new library locations. o Remove PathLib library class and make sure that BaseLib is described. • MdeModulePkg/MdeModulePkg.dec o Add SortLib library class • MdePkg/MdePkg.dec o Add FileHandleLib library class o Add PcdUefiFileHandleLibPrintBufferSize PCD • MdePkg/Library/BaseLib/BaseLib.inf o Add FilePaths.c to [Sources] • MdePkg/Include/Library/BaseLib.h o Update file description to include "file path functions" • ShellPkg/ShellPkg.dsc o Change PACKAGE_GUID to { C1014BB7-4092-43D4-984F-0738EB424DBF } o Update PACKAGE_VERSION to 1.0 o Update SortLib and FileHandleLib library classes to point to the new library locations. o Remove PathLib library class and make sure that BaseLib is described. o Remove ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf from [Components] • ShellPkg/ShellPkg.dec o Update PLATFORM_VERSION to 1.0 o Remove declarations of the FileHandleLib, SortLib, and PathLib Library Classes o Update comment for the PcdShellPrintBufferSize PCD. • ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf • ShellPkg/Application/Shell/Shell.inf o Remove PathLib from [LibraryClasses] • ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h • ShellPkg/Application/Shell/Shell.h o Remove #include <Library/PathLib.h> • ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf o Add PathLib to [LibraryClasses] • ShellPkg/Library/UefiShellLevel1CommandsLib/If.c o Remove #include <Library/PathLib.h> • ShellPkg/Application/ShellSortTestApp/ShellSortTestApp.inf o Add MdeModulePkg/MdeModulePkg.dec to [Packages] • MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf • MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf o Replace ShellPkg.dec with MdeModulePkg.dec in [Packages] • MdeModulePkg/Library/UefiSortLib/UefiSortLib.c o Remove #include <ShellBase.h> o Define USL_FREE_NON_NULL() to replace SHELL_FREE_NON_NULL() Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel <daryl.mcdaniel@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16601 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-13 02:04:07 +01:00
FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
!if $(SMM_REQUIRE) == FALSE
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
!endif
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
!ifdef $(SOURCE_DEBUG_ENABLE)
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf
!else
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
!endif
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
OvmfPkg: select LocalApicLib instance with x2apic support Although neither LocalApicLib instance is suitable for runtime DXE drivers (because they access the APIC at the physical address retrieved from either MSR_IA32_APIC_BASE_ADDRESS or PcdCpuLocalApicBaseAddress), they are suitable for SMM drivers -- SMM drivers are not influenced by the runtime OS's virtual address map. PiSmmCpuDxeSmm links against LocalApicLib. 64-bit Linux guests tend to enable x2apic mode even in simple VCPU configurations (e.g., 4 sockets, 1 core/socket, 1 thread/core): [ 0.028173] x2apic enabled If PiSmmCpuDxeSmm was linked with the BaseXApicLib instance (i.e., with no x2apic support), then the next runtime service call that is backed by an SMM driver triggers the following ASSERT in BaseXApicLib (because the latter notices that x2apic has been enabled, which it doesn't support): ASSERT .../UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c(263): ApicBaseMsr.Bits.Extd == 0 It is reasonable to give all LocalApicLib client modules in OVMF the same level of x2apic support, hence resolve LocalApicLib globally to BaseXApicX2ApicLib. This will not be conditional on -D SMM_REQUIRE, because BaseXApicX2ApicLib is compatible with BaseXApicLib in any environment where the latter can be used. 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@19052 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:31 +01:00
LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
!if $(TLS_ENABLE) == TRUE
OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
!else
OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
!endif
!if $(SECURE_BOOT_ENABLE) == TRUE
PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
!else
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
!endif
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
!if $(NETWORK_IP6_ENABLE) == TRUE
TcpIoLib|MdeModulePkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf
!endif
!if $(HTTP_BOOT_ENABLE) == TRUE
HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf
!endif
!if $(TLS_ENABLE) == TRUE
TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
!endif
OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot Script "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3 Boot Script, to be replayed in PEI during S3 Resume. The script contains opcodes and opcode arguments to configure CPU, PCI and IO resources. S3SaveStateDxe relies on the S3BootScriptLib library. The Null implementation is not useful for actually saving the boot script, we need the PiDxeS3BootScriptLib instance. The PiDxeS3BootScriptLib library instance depends on LockBoxLib, implemented for OVMF in one of the previous patches. PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null instance of the latter. It means that SMBus commands in the boot script will have no effect when interpreted during S3 Resume. This should be fine for OvmfPkg and QEMU. EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] S3BootScriptLib [PiDxeS3BootScriptLib] SmbusLib [BaseSmbusLibNull] LockBoxLib [OvmfPkg/Library/LockBoxLib] When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely as a form of notification), the S3SaveStateDxe driver saves the boot script to EfiACPIMemoryNVS, and links it into the LockBox. 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@15304 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 09:03:50 +01:00
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot Script "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3 Boot Script, to be replayed in PEI during S3 Resume. The script contains opcodes and opcode arguments to configure CPU, PCI and IO resources. S3SaveStateDxe relies on the S3BootScriptLib library. The Null implementation is not useful for actually saving the boot script, we need the PiDxeS3BootScriptLib instance. The PiDxeS3BootScriptLib library instance depends on LockBoxLib, implemented for OVMF in one of the previous patches. PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null instance of the latter. It means that SMBus commands in the boot script will have no effect when interpreted during S3 Resume. This should be fine for OvmfPkg and QEMU. EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] S3BootScriptLib [PiDxeS3BootScriptLib] SmbusLib [BaseSmbusLibNull] LockBoxLib [OvmfPkg/Library/LockBoxLib] When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely as a form of notification), the S3SaveStateDxe driver saves the boot script to EfiACPIMemoryNVS, and links it into the LockBox. 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@15304 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 09:03:50 +01:00
[LibraryClasses.common]
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
[LibraryClasses.common.SEC]
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
!ifdef $(SOURCE_DEBUG_ENABLE)
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
!endif
HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
[LibraryClasses.common.PEI_CORE]
HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
[LibraryClasses.common.PEIM]
HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
PeiResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf
ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf
!ifdef $(SOURCE_DEBUG_ENABLE)
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
!endif
OvmfPkg: include UefiCpuPkg/CpuMpPei In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use. CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those already used by CpuDxe: - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these control whether CpuMpPei performs microcode update. If the region size is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the region size to zero by default, which is appropriate for OVMF. - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait (with PAUSE). The latter PCD is only relevant if the former PCD is 2 (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself, we choose HLT. That's the default set by UefiCpuPkg.dec. Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib technically, it is supposed to consume PeiCpuExceptionHandlerLib. See: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703 - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module"), part of the series linked above. Jeff recommended to resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all PEIMs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477 Since at the moment we have no resolution in place that would cover this for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]), it's easy to do. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-06 18:09:16 +02:00
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
[LibraryClasses.common.DXE_CORE]
HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
!ifdef $(SOURCE_DEBUG_ENABLE)
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
!endif
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
OvmfPkg: make PcdPropertiesTableEnable dynamic Since PcdPropertiesTableEnable is used by the DXE Core (in the InstallPropertiesTable() function, which runs at End-of-Dxe), we must also change the PcdLib class resolution for that module, from the default BasePcdLibNull to DxePcdLib. Traditionally we've considered the DXE Core to be incapable of accessing dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core, and the PCD Protocol is not available to it *yet*. There are exceptions however: if the DXE Core can ensure, by whatever means, that the PCD Protocol *is* available, then DxePcdLib will just work (the latter even lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks up the PCD Protocol dynamically, on the first library call that actually needs it (for accessing a dynamic PCD); the lookup doesn't occur in a library constructor. And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe, the PCD Protocol is definitely available then. In addition, we change the default value of PcdPropertiesTableEnable from the inherited TRUE to FALSE. It makes no difference at this point (our runtime DXE drivers are not built with the required 4KB section alignment anyway), but it's better to be clear about this. The properties table feature requires OS compatibility, and it breaks Windows 7 minimally. Therefore the default should be FALSE. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> 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@18470 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-15 10:35:08 +02:00
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
[LibraryClasses.common.DXE_RUNTIME_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
[LibraryClasses.common.UEFI_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
[LibraryClasses.common.DXE_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
IpIoLib|MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.inf
UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
!if $(SMM_REQUIRE) == TRUE
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
!else
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
!endif
!ifdef $(SOURCE_DEBUG_ENABLE)
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
[LibraryClasses.common.UEFI_APPLICATION]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
[LibraryClasses.common.DXE_SMM_DRIVER]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
!ifdef $(SOURCE_DEBUG_ENABLE)
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
!endif
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
[LibraryClasses.common.SMM_CORE]
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
!ifdef $(DEBUG_ON_SERIAL_PORT)
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
!else
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
!endif
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
################################################################################
#
# Pcd Section - list of all EDK II PCD Entries defined by this Platform.
#
################################################################################
[PcdsFeatureFlag]
gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportUefiDecompress|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
!if $(SMM_REQUIRE) == TRUE
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
!endif
[PcdsFixedAtBuild]
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x10
gEfiMdeModulePkgTokenSpaceGuid.PcdPeiCoreMaxFvSupported|6
gEfiMdeModulePkgTokenSpaceGuid.PcdPeiCoreMaxPeimPerFv|32
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
!endif
!if $(FD_SIZE_IN_KB) == 4096
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x40000
!endif
gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
# DEBUG_INIT 0x00000001 // Initialization
# DEBUG_WARN 0x00000002 // Warnings
# DEBUG_LOAD 0x00000004 // Load events
# DEBUG_FS 0x00000008 // EFI File system
# DEBUG_POOL 0x00000010 // Alloc & Free (pool)
# DEBUG_PAGE 0x00000020 // Alloc & Free (page)
# DEBUG_INFO 0x00000040 // Informational debug messages
# DEBUG_DISPATCH 0x00000080 // PEI/DXE/SMM Dispatchers
# DEBUG_VARIABLE 0x00000100 // Variable
# DEBUG_BM 0x00000400 // Boot Manager
# DEBUG_BLKIO 0x00001000 // BlkIo Driver
# DEBUG_NET 0x00004000 // SNP Driver
# DEBUG_UNDI 0x00010000 // UNDI Driver
# DEBUG_LOADFILE 0x00020000 // LoadFile
# DEBUG_EVENT 0x00080000 // Event messages
# DEBUG_GCD 0x00100000 // Global Coherency Database changes
# DEBUG_CACHE 0x00200000 // Memory range cachability changes
# DEBUG_VERBOSE 0x00400000 // Detailed debug messages that may
# // significantly impact boot performance
# DEBUG_ERROR 0x80000000 // Error
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8000004F
!ifdef $(SOURCE_DEBUG_ENABLE)
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
!else
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
!endif
OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35 The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Micha Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Micha Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Micha Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 20:46:22 +01:00
# This PCD is used to set the base address of the PCI express hierarchy. It
# is only consulted when OVMF runs on Q35. In that case it is programmed into
# the PCIEXBAR register.
#
# On Q35 machine types that QEMU intends to support in the long term, QEMU
# never lets the RAM below 4 GB exceed 2 GB.
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x80000000
!ifdef $(SOURCE_DEBUG_ENABLE)
gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2
!endif
!if $(HTTP_BOOT_ENABLE) == TRUE
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
!endif
!ifndef $(USE_OLD_SHELL)
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
!endif
!if $(SMM_REQUIRE) == TRUE
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
!endif
OvmfPkg: execute option ROM images regardless of Secure Boot Change the image verification policy for option ROM images to 0x00 (ALWAYS_EXECUTE). While this may not be a good idea for physical platforms (see e.g. <https://trmm.net/Thunderstrike>), on the QEMU platform the benefits seem to outweigh the drawbacks: - For QEMU's virtual PCI devices, and for some assigned PCI devices, the option ROMs come from host-side files, which can never be rewritten from within the guest. Since the host admin has full control over a guest anyway, executing option ROMs that originate from host-side files presents no additional threat to the guest. - For assigned physical PCI devices with option ROMs, the argument is not so clear-cut. In theory a setup could exist where: - the host-side UEFI firmware (with DENY_EXECUTE_ON_SECURITY_VIOLATION) rejects the option ROM of a malicious physical PCI device, but - when the device is assigned to the guest, OVMF executes the option ROM in the guest, - the option ROM breaks out of the guest (using an assumed QEMU vulnerability) and gains QEMU user privileges on the host. However, in order to escalate as far as it would happen on the bare metal with ALWAYS_EXECUTE (i.e., in order to gain firmware-level access on the host), the malicious option ROM would have to break through (1) QEMU, (2) traditional UID and GID based privilege separation on the host, (3) sVirt (SELinux) on the host, (4) the host OS - host firmware boundary. This is not impossible, but not likely enough to discourage the use cases below. - This patch makes it possible to use unsigned iPXE network drivers that QEMU presents in the option ROMs of virtual NICs and assigned SR-IOV VFs, even if Secure Boot is in User Mode or Deployed Mode. - The change also makes it possible to execute unsigned, outdated (revoked), or downright malicious option ROMs of assigned physical devices in guests, for corporate, entertainment, academia, or security research purposes. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19614 6f19259b-4bc3-4df7-8a09-765794883524
2016-01-07 19:48:17 +01:00
!if $(SECURE_BOOT_ENABLE) == TRUE
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
!endif
# IRQs 5, 9, 10, 11 are level-triggered
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
################################################################################
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
#
################################################################################
[PcdsDynamicDefault]
# only set when
# ($(SMM_REQUIRE) == FALSE)
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
# Set video resolution for text setup.
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution|640
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution|480
OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to 3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the version number of the SMBIOS entry point table (and other things) that "MdeModulePkg/Universal/SmbiosDxe" installs. Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7); those are limited to 2.x (both in the guest kernel firmware driver, and in the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID -- defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize it. The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware to install. The payload includes the entry point table ("anchor" table). OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe" driver); however, we can parse the entry point version from QEMU's anchor table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that version. On machine types older than v2.1.0, the feature is not available, but then, should anything in OVMF install SMBIOS tables, version 2.8 is simply safer / more widely supported than 3.0 -- hence the default 2.8 value for the dynamic PCD. We set the PCD in PlatformPei (when not on the S3 resume path), because that's an easy and certain way to set the PCD before a DXE driver reads it. This follows the example of PcdEmuVariableNvStoreReserved (which is read by EmuVariableFvbRuntimeDxe). RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876 Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-22 19:11:05 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0208
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0
gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to 3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the version number of the SMBIOS entry point table (and other things) that "MdeModulePkg/Universal/SmbiosDxe" installs. Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7); those are limited to 2.x (both in the guest kernel firmware driver, and in the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID -- defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize it. The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware to install. The payload includes the entry point table ("anchor" table). OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe" driver); however, we can parse the entry point version from QEMU's anchor table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that version. On machine types older than v2.1.0, the feature is not available, but then, should anything in OVMF install SMBIOS tables, version 2.8 is simply safer / more widely supported than 3.0 -- hence the default 2.8 value for the dynamic PCD. We set the PCD in PlatformPei (when not on the S3 resume path), because that's an easy and certain way to set the PCD before a DXE driver reads it. This follows the example of PcdEmuVariableNvStoreReserved (which is read by EmuVariableFvbRuntimeDxe). RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876 Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-22 19:11:05 +02:00
# Noexec settings for DXE.
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
OvmfPkg: make PcdPropertiesTableEnable dynamic Since PcdPropertiesTableEnable is used by the DXE Core (in the InstallPropertiesTable() function, which runs at End-of-Dxe), we must also change the PcdLib class resolution for that module, from the default BasePcdLibNull to DxePcdLib. Traditionally we've considered the DXE Core to be incapable of accessing dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core, and the PCD Protocol is not available to it *yet*. There are exceptions however: if the DXE Core can ensure, by whatever means, that the PCD Protocol *is* available, then DxePcdLib will just work (the latter even lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks up the PCD Protocol dynamically, on the first library call that actually needs it (for accessing a dynamic PCD); the lookup doesn't occur in a library constructor. And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe, the PCD Protocol is definitely available then. In addition, we change the default value of PcdPropertiesTableEnable from the inherited TRUE to FALSE. It makes no difference at this point (our runtime DXE drivers are not built with the required 4KB section alignment anyway), but it's better to be clear about this. The properties table feature requires OS compatibility, and it breaks Windows 7 minimally. Therefore the default should be FALSE. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> 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@18470 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-15 10:35:08 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
# UefiCpuPkg PCDs related to initial AP bringup and general AP management.
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64
gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds|50000
!if $(SMM_REQUIRE) == TRUE
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
!endif
################################################################################
#
# Components Section - list of all EDK II Modules needed by this Platform.
#
################################################################################
[Components]
OvmfPkg/ResetVector/ResetVector.inf
#
# SEC Phase modules
#
OvmfPkg/Sec/SecMain.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
}
#
# PEI Phase modules
#
MdeModulePkg/Core/Pei/PeiMain.inf
MdeModulePkg/Universal/PCD/Pei/Pcd.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
OvmfPkg/PlatformPei/PlatformPei.inf
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
<LibraryClasses>
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
!if $(SMM_REQUIRE) == TRUE
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
!endif
}
OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the LockBoxLib instance with SMRAM access for the PEI phase. Said library instance must, and can, access the LockBox data in SMRAM directly if it is invoked before SMBASE relocation / SMI handler installation. In that case, it only needs PEI_SMM_ACCESS_PPI from the platform, and it doesn't depend on EFI_PEI_SMM_COMMUNICATION_PPI. OVMF satisfies the description in SVN r18823 ("MdeModulePkg: SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI"): in OVMF, only S3Resume2Pei links against SmmLockBoxPeiLib. Therefore, introduce a PEIM that produces the PEI_SMM_ACCESS_PPI interface, enabling SmmLockBoxPeiLib to work; we can omit including "UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf". The load / installation order of S3Resume2Pei and SmmAccessPei is indifferent. SmmAccessPei produces the gEfiAcpiVariableGuid HOB during its installation (which happens during PEI), but S3Resume2Pei accesses the HOB only when the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI. MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to prevent VS20xx from warning about the (otherwise fully intentional) truncation in the UINT8 casts. (Warnings reported by Michael Kinney.) Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19040 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:38 +01:00
!if $(SMM_REQUIRE) == TRUE
OvmfPkg/SmmAccess/SmmAccessPei.inf
OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the LockBoxLib instance with SMRAM access for the PEI phase. Said library instance must, and can, access the LockBox data in SMRAM directly if it is invoked before SMBASE relocation / SMI handler installation. In that case, it only needs PEI_SMM_ACCESS_PPI from the platform, and it doesn't depend on EFI_PEI_SMM_COMMUNICATION_PPI. OVMF satisfies the description in SVN r18823 ("MdeModulePkg: SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI"): in OVMF, only S3Resume2Pei links against SmmLockBoxPeiLib. Therefore, introduce a PEIM that produces the PEI_SMM_ACCESS_PPI interface, enabling SmmLockBoxPeiLib to work; we can omit including "UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf". The load / installation order of S3Resume2Pei and SmmAccessPei is indifferent. SmmAccessPei produces the gEfiAcpiVariableGuid HOB during its installation (which happens during PEI), but S3Resume2Pei accesses the HOB only when the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI. MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to prevent VS20xx from warning about the (otherwise fully intentional) truncation in the UINT8 casts. (Warnings reported by Michael Kinney.) Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19040 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:38 +01:00
!endif
UefiCpuPkg/CpuMpPei/CpuMpPei.inf
#
# DXE Phase modules
#
MdeModulePkg/Core/Dxe/DxeMain.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
}
OvmfPkg: use StatusCode Router and Handler from MdeModulePkg In the Platform Init v1.4a spec, - Volume 1 "4.7 Status Code Service" defines the EFI_PEI_SERVICES.ReportStatusCode() service, - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), - Volume 2 "14.2 Status Code Runtime Protocol" defines the EFI_STATUS_CODE_PROTOCOL. These allow PEIMs and DXE (and later) modules to report status codes. Currently OvmfPkg uses modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above abstractions (PPI and PROTOCOL) directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. In the Platform Init v1.4a spec, - Volume 3 "7.2.2 Report Status Code Handler PPI" defines EFI_PEI_RSC_HANDLER_PPI, - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines EFI_RSC_HANDLER_PROTOCOL. These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com> Suggested-by: Liming Gao <liming.gao@intel.com> Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63 [jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-08-02 19:25:10 +02:00
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
!if $(SECURE_BOOT_ENABLE) == TRUE
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
<LibraryClasses>
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
}
!else
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
!endif
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
UefiCpuPkg/CpuDxe/CpuDxe.inf
PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM According to edk2 commit "MdeModulePkg/PciBus: do not improperly degrade resource" and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the Platform Init 1.4a specification, a platform can provide such a protocol in order to influence the PCI resource allocation performed by the PCI Bus driver. In particular it is possible instruct the PCI Bus driver, with a "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit address space, regardless of whether the device features an option ROM. (By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS binary from a combined option ROM could be dispatched, and fail to access MMIO BARs in 64-bit address space.) In platform code we can ascertain whether a CSM is present or not. If not, then legacy BIOS binaries in option ROMs can't be dispatched, hence the BAR degradation is detrimental, and we should prevent it. This is expected to conserve the 32-bit address space for 32-bit MMIO BARs. The driver added in this patch could be simplified based on the following facts: - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence the driver will exit immediately. Therefore the driver could be omitted from the Ia32 build. - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE was defined (because in that case the degradation would be justified). On the other hand, if CSM_ENABLE was undefined, then the driver could be included, and it could provide the hint unconditionally (without looking for the Legacy BIOS protocol). These short-cuts are not taken because they would increase the differences between the OVMF DSC/FDF files. If we can manage without extreme complexity, we should use dynamic logic (vs. build time configuration), plus keep conditional compilation to a minimum. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-05-18 20:13:41 +02:00
OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
OvmfPkg: add PciHotPlugInitDxe After IncompatiblePciDeviceSupportDxe, this is another small driver / protocol implementation that tweaks the behavior of the PCI bus driver in edk2. The protocol is specified in the Platform Init Spec v1.4a, Volume 5, Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This implementation steers the PCI bus driver to reserve the following resources ("padding") for each PCI bus, in addition to the BARs of the devices on that PCI bus: - 2MB of 64-bit non-prefetchable MMIO aperture, - 512B of IO port space. The goal is to reserve room for devices hot-plugged at runtime even if the bridge receiving the device is empty at boot time. The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is actually only 1/8th of the PCI spec mandated reservation, but the specified size of 4096 has proved wasteful (given the limited size of our IO port space -- see commit bba734ab4c7c). Especially on Q35, where every PCIe root port and downstream port qualifies as a separate bridge (capable of accepting a single device). Test results for this patch: - regardless of our request for 64-bit MMIO reservation, it is downgraded to 32-bit, - although we request 512B alignment for the IO port space reservation, the next upstream bridge rounds it up to 4096B. Cc: "Johnson, Brian J." <bjohnson@sgi.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
2016-06-30 20:16:06 +02:00
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
<LibraryClasses>
PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
}
MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
}
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
MdeModulePkg/Universal/Metronome/Metronome.inf
PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
<LibraryClasses>
!ifdef $(CSM_ENABLE)
NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
!endif
}
MdeModulePkg/Logo/LogoDxe.inf
MdeModulePkg/Application/UiApp/UiApp.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
!ifdef $(CSM_ENABLE)
NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
!endif
}
OvmfPkg/BlockMmioToBlockIoDxe/BlockIo.inf
OvmfPkg: Make the VirtIo devices use the new VIRTIO_DEVICE_PROTOCOL This change replaces the accesses to the PCI bus from the Block, Scsi and Net drivers by the use of the new VIRTIO_DEVICE_PROTOCOL protocol that abstracts the transport layer. It means these drivers can be used on PCI and MMIO transport layer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - VirtioFlush(): update comment block in VirtioLib.[hc]; error code is propagated from VirtIo->SetQueueNotify(). - VirtioBlkInit(): jump to Failed label if SetPageSize() fails - VirtioBlkInit(): fixup comment, and add error handling, near SetQueueNum() call - VirtioBlkDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_BLOCK_DEVICE; VirtioBlkDriverBindingSupported() handles it already - VirtioNetGetFeatures(): update stale comment block - VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded loop) - VirtioNetDriverBindingStart(): remove redundant (always false) check for a subsystem device ID different from VIRTIO_SUBSYSTEM_NETWORK_CARD; VirtioNetDriverBindingSupported() handles it already - VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation - VirtioNetInitialize(): fix destination error label for when SetPageSize() fails - VirtioScsi.c: fix comment block of VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ() - VirtioScsiInit(): fix destination error label for when SetPageSize() fails - VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper MMIO operation 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@14966 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11 17:58:22 +01:00
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
OvmfPkg/Virtio10Dxe/Virtio10.inf
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/VirtioRngDxe/VirtioRng.inf
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
}
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf {
<LibraryClasses>
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
FatPkg/EnhancedFatDxe/Fat.inf
MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
OvmfPkg: enable SATA controller In this patch, we replace the traditional IDE driver stack that comes from PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible with the previous one, but provides more protocols, on more kinds of virtual hardware. Remove: - PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf (removing EFI_IDE_CONTROLLER_INIT_PROTOCOL [1]) Remove the dependent: - IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf (removing EFI_DISK_INFO_PROTOCOL [2], EFI_BLOCK_IO_PROTOCOL [3]) As replacement, add: - OvmfPkg/SataControllerDxe/SataControllerDxe.inf (supplying EFI_IDE_CONTROLLER_INIT_PROTOCOL [1]) On top of which, add the dependent: - MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf (providing EFI_ATA_PASS_THRU_PROTOCOL, EFI_EXT_SCSI_PASS_THRU_PROTOCOL) On top of which, add the dependent: - MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf (supplying EFI_DISK_INFO_PROTOCOL [2], EFI_BLOCK_IO_PROTOCOL [3], providing EFI_BLOCK_IO2PROTOCOL, EFI_STORAGE_SECURITY_COMMAND_PROTOCOL) Cc: Alexander Graf <agraf@suse.de> Cc: Reza Jelveh <reza.jelveh@tuhh.de> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Gabriel L. Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de> [lersek@redhat.com: rewrote commit message] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18532 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-22 13:18:45 +02:00
OvmfPkg/SataControllerDxe/SataControllerDxe.inf
MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
#
# ISA Support
#
PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe/IsaFloppyDxe.inf
#
# SMBIOS Support
#
MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
<LibraryClasses>
NULL|OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf
}
OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
#
# ACPI Support
#
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
OvmfPkg/AcpiTables/AcpiTables.inf
OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot Script "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3 Boot Script, to be replayed in PEI during S3 Resume. The script contains opcodes and opcode arguments to configure CPU, PCI and IO resources. S3SaveStateDxe relies on the S3BootScriptLib library. The Null implementation is not useful for actually saving the boot script, we need the PiDxeS3BootScriptLib instance. The PiDxeS3BootScriptLib library instance depends on LockBoxLib, implemented for OVMF in one of the previous patches. PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null instance of the latter. It means that SMBus commands in the boot script will have no effect when interpreted during S3 Resume. This should be fine for OvmfPkg and QEMU. EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] S3BootScriptLib [PiDxeS3BootScriptLib] SmbusLib [BaseSmbusLibNull] LockBoxLib [OvmfPkg/Library/LockBoxLib] When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely as a form of notification), the S3SaveStateDxe driver saves the boot script to EfiACPIMemoryNVS, and links it into the LockBox. 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@15304 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 09:03:50 +01:00
MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
OvmfPkg: Install BGRT ACPI table While debugging OS for ACPI BGRT support (especially on VMs), it is very useful to have the EFI firmware (OVMF in most cases which use Tianocore) to export the ACPI BGRT table. This patch tries to add this support in OvmfPkg. Tested this patch in the following environments: 1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host: - Ensured that the BGRT logo is properly prepared and can be viewed with user-space tools (like 'Gwenview' on KDE, for example): $ file /sys/firmware/acpi/bgrt/image /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x 58 x 24 2. On a Windows-10 VM Guest running on a Fedora-24 Host: - Ensured that the BGRT ACPI table is properly prepared and can be read with freeware tool like FirmwareTablesView: ================================================== Signature : BGRT Firmware Provider : ACPI Length : 56 Revision : 1 Checksum : 129 OEM ID : INTEL OEM Table ID : EDK2 OEM Revision : 0x00000002 Creator ID : 0x20202020 Creator Revision : 0x01000013 Description : ================================================== Note from Laszlo Ersek <lersek@redhat.com>: without the BGRT ACPI table, Windows 8 and Windows 10 first clear the screen, then display a blue, slanted Windows picture above the rotating white boot animation. With the BGRT ACPI table, Windows 8 and Windows 10 don't clear the screen, the blue Windows image is not displayed, and the rotating white boot animation is shown between the firmware's original TianoCore boot splash and (optional) "Start boot option" progress bar. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: cover effect on Windows 8/10 boot anim. in commit msg] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-01-06 10:47:15 +01:00
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
#
# Network Support
#
MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
!if $(NETWORK_IP6_ENABLE) == TRUE
NetworkPkg/Ip6Dxe/Ip6Dxe.inf
NetworkPkg/TcpDxe/TcpDxe.inf
NetworkPkg/Udp6Dxe/Udp6Dxe.inf
NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
NetworkPkg/IScsiDxe/IScsiDxe.inf
!else
MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf
!endif
!if $(HTTP_BOOT_ENABLE) == TRUE
NetworkPkg/DnsDxe/DnsDxe.inf
NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
NetworkPkg/HttpDxe/HttpDxe.inf
NetworkPkg/HttpBootDxe/HttpBootDxe.inf
!endif
!if $(TLS_ENABLE) == TRUE
NetworkPkg/TlsDxe/TlsDxe.inf
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
!endif
OvmfPkg/VirtioNetDxe/VirtioNet.inf
#
# Usb Support
#
MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
!ifdef $(CSM_ENABLE)
IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
}
IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
OvmfPkg/Csm/Csm16/Csm16.inf
!endif
!ifndef $(USE_OLD_SHELL)
ShellPkg/Application/Shell/Shell.inf {
<LibraryClasses>
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
!if $(NETWORK_IP6_ENABLE) == TRUE
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
!endif
NULL|ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.inf
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
MdeModulePkg, MdePkg, NetworkPkg, OvmfPkg, PerformancePkg, ShellPkg: Library Migration. Move libraries from ShellPkg into MdeModulePkg and MdePkg. The following libraries are being migrated out of ShellPkg in order to make their functionality more widely available. • PathLib: Incorporate into MdePkg/Library/BaseLib • FileHandleLib: MdePkg/Library/UefiFileHandleLib • BaseSortLib: MdeModulePkg/Library/BaseSortLib • UefiSortLib: MdeModulePkg/Library/UefiSortLib Diffs showing file changes are in the attached file, LibMigration.patch. A description of the changes follows: • Move ShellPkg/Include/Library/FileHandleLib.h to MdePkg/Include/Library/FileHandleLib.h • Move ShellPkg/Include/Library/SortLib.h to MdeModulePkg/Include/Library/SortLib.h • Move ShellPkg/Library/BaseSortLib to MdeModulePkg/Library/BaseSortLib • Move ShellPkg/Library/UefiSortLib to MdeModulePkg/Library/UefiSortLib • Move ShellPkg/Library/BasePathLib/BasePathLib.c to MdePkg/Library/BaseLib/FilePaths.c • Merge ShellPkg/Include/Library/PathLib.h into MdePkg/Include/Library/BaseLib.h • Delete ShellPkg/Library/BasePathLib; Includes BasePathLib.c and BasePathLib.inf • NetworkPkg/NetworkPkg.dsc • PerformancePkg.dsc • OvmfPkg/OvmfPkgX64.dsc • OvmfPkg/OvmfPkgIa32X64.dsc • OvmfPkg/OvmfPkgIa32.dsc o Update SortLib and FileHandleLib library classes to point to the new library locations. o Remove PathLib library class and make sure that BaseLib is described. • MdeModulePkg/MdeModulePkg.dec o Add SortLib library class • MdePkg/MdePkg.dec o Add FileHandleLib library class o Add PcdUefiFileHandleLibPrintBufferSize PCD • MdePkg/Library/BaseLib/BaseLib.inf o Add FilePaths.c to [Sources] • MdePkg/Include/Library/BaseLib.h o Update file description to include "file path functions" • ShellPkg/ShellPkg.dsc o Change PACKAGE_GUID to { C1014BB7-4092-43D4-984F-0738EB424DBF } o Update PACKAGE_VERSION to 1.0 o Update SortLib and FileHandleLib library classes to point to the new library locations. o Remove PathLib library class and make sure that BaseLib is described. o Remove ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf from [Components] • ShellPkg/ShellPkg.dec o Update PLATFORM_VERSION to 1.0 o Remove declarations of the FileHandleLib, SortLib, and PathLib Library Classes o Update comment for the PcdShellPrintBufferSize PCD. • ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf • ShellPkg/Application/Shell/Shell.inf o Remove PathLib from [LibraryClasses] • ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h • ShellPkg/Application/Shell/Shell.h o Remove #include <Library/PathLib.h> • ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf o Add PathLib to [LibraryClasses] • ShellPkg/Library/UefiShellLevel1CommandsLib/If.c o Remove #include <Library/PathLib.h> • ShellPkg/Application/ShellSortTestApp/ShellSortTestApp.inf o Add MdeModulePkg/MdeModulePkg.dec to [Packages] • MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf • MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf o Replace ShellPkg.dec with MdeModulePkg.dec in [Packages] • MdeModulePkg/Library/UefiSortLib/UefiSortLib.c o Remove #include <ShellBase.h> o Define USL_FREE_NON_NULL() to replace SHELL_FREE_NON_NULL() Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel <daryl.mcdaniel@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16601 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-13 02:04:07 +01:00
FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
# SafeBlockIoLib|ShellPkg/Library/SafeBlockIoLib/SafeBlockIoLib.inf
# SafeOpenProtocolLib|ShellPkg/Library/SafeOpenProtocolLib/SafeOpenProtocolLib.inf
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
<PcdsFixedAtBuild>
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
}
!endif
!if $(SECURE_BOOT_ENABLE) == TRUE
OvmfPkg: disable stale fork of SecureBootConfigDxe OvmfPkg forked SecureBootConfigDxe from SecurityPkg in SVN r13635 (git commit 8c71ec8f). Since then, the original (in "SecurityPkg/VariableAuthenticated/SecureBootConfigDxe") has diverged significantly. The initial diff between the original and the fork, when the fork was made (ie. at SVN r13635), reads as follows: > diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr > --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr 2014-09-30 23:35:28.598067147 +0200 > +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr 2014-08-09 02:40:35.824851626 +0200 > @@ -51,7 +51,7 @@ > questionid = KEY_SECURE_BOOT_ENABLE, > prompt = STRING_TOKEN(STR_SECURE_BOOT_PROMPT), > help = STRING_TOKEN(STR_SECURE_BOOT_HELP), > - flags = INTERACTIVE | RESET_REQUIRED, > + flags = INTERACTIVE, > endcheckbox; > endif; > > @@ -158,7 +158,7 @@ > questionid = KEY_SECURE_BOOT_DELETE_PK, > prompt = STRING_TOKEN(STR_DELETE_PK), > help = STRING_TOKEN(STR_DELETE_PK_HELP), > - flags = INTERACTIVE | RESET_REQUIRED, > + flags = INTERACTIVE, > endcheckbox; > endif; > endform; > diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf > --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.598067147 +0200 > +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.577067027 +0200 > @@ -1,5 +1,8 @@ > ## @file > -# Component name for SecureBoot configuration module. > +# Component name for SecureBoot configuration module for OVMF. > +# > +# Need custom SecureBootConfigDxe for OVMF that does not force > +# resets after PK changes since OVMF doesn't have persistent variables > # > # Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.<BR> > # This program and the accompanying materials > diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c > --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.599067153 +0200 > +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.578067033 +0200 > @@ -2559,7 +2559,7 @@ > NULL > ); > } else { > - *ActionRequest = EFI_BROWSER_ACTION_REQUEST_RESET; > + *ActionRequest = EFI_BROWSER_ACTION_REQUEST_SUBMIT; > } > break; The commit message is not overly verbose: OvmfPkg: Add custom SecureBootConfigDxe that doesn't reset We don't force a platform reset for OVMF when PK is changed in custom mode setup. But the INF file hunk is telling: Need custom SecureBootConfigDxe for OVMF that does not force resets after PK changes since OVMF doesn't have persistent variables We do have persistent variables now. Let's disable the (now obsolete) OvmfPkg fork, and revert to the (well maintained) SecurityPkg-provided config driver. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gary Lin <glin@suse.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16191 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-02 10:08:05 +02:00
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
!endif
OvmfPkg/PlatformDxe/Platform.inf
!if $(SMM_REQUIRE) == TRUE
OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
2015-11-30 19:46:55 +01:00
UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
#
# SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
#
MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
#
# SMM_CORE
#
MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
#
# Privileged drivers (DXE_SMM_DRIVER modules)
#
UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. 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@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:42:15 +01:00
MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
<LibraryClasses>
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
}
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
<LibraryClasses>
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
}
#
# Variable driver stack (SMM)
#
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
}
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
!else
#
# Variable driver stack (non-SMM)
#
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
<LibraryClasses>
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
}
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
}
!endif