Ard Biesheuvel [Tue, 8 Dec 2015 07:40:12 +0000 (07:40 +0000)]
BaseTools GCC: avoid the use of COMMON symbols
The default behavior of the GCC compiler is to emit uninitialized globals
with external linkage into a COMMON section, where duplicate definitions
are merged. This may result in unexpected behavior, since global variables
defined under the same name in different C files may not refer to the same
logical data item.
For instance, the definitions of EFI_EVENT mVirtualAddressChangeEvent that
[used to] appear in the following files:
will be folded into a single instance of the variable when the latter
module includes the former library, which can lead to unexpected results.
Even if some may argue that there are legal uses for COMMON allocation, the
high modularity of EDK2 combined with the low level of awareness of the
intracicies surrounding common allocation and the generally poor EDK2
developer discipline regarding the use of the STATIC keyword* make a strong
case for disabling it by default, and re-enabling it explicitly for packages
that depend on it.
So prevent GCC from emitting variables into the COMMON section, by passing
-fno-common to the compiler, and discarding the section in the GNU ld linker
script.
* Any function or variable that is only referenced from the translation unit
that defines it could be made STATIC. This does not only prevent issues
like the above, it also allows the compiler to generate better code, e.g.,
drop out of line function definitions after inlining all invocations or
perform constant propagation on variables.
Ard Biesheuvel [Tue, 8 Dec 2015 07:35:30 +0000 (07:35 +0000)]
ArmPkg/PrePeiCore: adhere to architectural stack alignment requirement
Instead of using fuzzy arithmetic with a hardcoded stack alignment value
of 0x4, use the symbolic constant CPU_STACK_ALIGNMENT (which is at least
8 bytes, btw) to round the temporary stack base and size.
Add new API MtrrSetMemoryAttributeInMtrrSettings() in MtrrLib. Platform could
use this API to set MTRR setting into local MTRR settings buffer instead of
MTRRs. At last, platform could use MtrrSetAllMtrrs() to set the MTRR settings
into MTRRs totally. It could improve MTRRs programming performance obviously,
specially when platform is going to program a set of MTRRs.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19162 6f19259b-4bc3-4df7-8a09-765794883524
Michael Kinney [Tue, 8 Dec 2015 05:24:18 +0000 (05:24 +0000)]
UefiCpuPkg/MtrrLib: Reduce hardware init when program variable MTRRs
When MtrrSetMemoryAttribute() programs variable MTRRs, it may disable/enable
cache and disable/enable MTRRs several times. This updating tries to do
operation in local variable and does the hardware initialization one time only.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19158 6f19259b-4bc3-4df7-8a09-765794883524
Michael Kinney [Tue, 8 Dec 2015 05:23:44 +0000 (05:23 +0000)]
UefiCpuPkg/MtrrLib: Reduce hardware init when program fixed MTRRs
When MtrrSetMemoryAttribute() programs fixed MTRRs, it may disable/enable cache
and disable/enable MTRRs several times. This updating tries to do operation in
local variable and does the hardware initialization one time only.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19157 6f19259b-4bc3-4df7-8a09-765794883524
Add function to shadow the content of variable MTRRs into an internal array:
VariableMtrr. And used MtrrGetMemoryAttributeInVariableMtrrWorker() in other
functions.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19156 6f19259b-4bc3-4df7-8a09-765794883524
Michael Kinney [Tue, 8 Dec 2015 05:21:24 +0000 (05:21 +0000)]
UefiCpuPkg/MtrrLib: Add worker functions not invoke IsMtrrSupported()
Abstract some worker functions not to invoke IsMtrrSupported(). They could be
used by other functions to reduce the number of invoking times on
IsMtrrSupported().
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19153 6f19259b-4bc3-4df7-8a09-765794883524
Current MtrrLib reserves 2 variable MTRRs for some legacy OS boot (CSM boots)
may require some MTRRs to be reserved for OS use. But UEFI OS boot will not use
MTRRs.
Per Scott's suggestion in link: http://article.gmane.org/gmane.comp.bios.edk2.devel/4099
Add one PCD PcdCpuNumberOfReservedVariableMtrrs to specify the number of
variable MTRRs reserved for OS use. Setting its default value to 2 is for
back-compatibility.
Cc: Scott Duplichan <scott@notabs.org> Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Suggested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19151 6f19259b-4bc3-4df7-8a09-765794883524
Qiu Shumin [Tue, 8 Dec 2015 02:00:16 +0000 (02:00 +0000)]
ShellPkg: Refine the code to reduce time cost of 'map -r'
In some platform 'map -r' may cost more than 1 min. This patch filter the target handles by
BlockIO and SimpleFileSystem protocol to reduce the time cost.
Heyi Guo [Mon, 7 Dec 2015 16:51:35 +0000 (16:51 +0000)]
ArmPkg/BdsLib: Send RemainingDevicePath to PXE Load File protocol
Load File protocol requires remaining device path rather than whole
device path. For PXE, it actually requires end node device path only,
or else invalid parameter will be returned directly.
Ard Biesheuvel [Mon, 7 Dec 2015 09:20:20 +0000 (09:20 +0000)]
CryptoPkg/BaseCryptLib: make mVirtualAddressChangeEvent STATIC
Make mVirtualAddressChangeEvent STATIC to prevent it from conflicting
with other variables of the same name that may be defined in other
libraries (e.g., MdeModulePkg/Universal/Variable/RuntimeDxe)
This also removes the risk of mVirtualAddressChangeEvent being merged with
other uninitialized variables with external linkage by toolchains that perform
COMMON allocation.
Yonghong Zhu [Mon, 7 Dec 2015 09:09:31 +0000 (09:09 +0000)]
BaseTools: process the files by the priority in BUILDRULEORDER
By the BUILDRULEORDER feature to process files listed in INF [Sources]
sections in priority order, if a filename is listed with multiple
extensions, the tools will use only the file that matches the first
extension in the space separated list.
Yonghong Zhu [Mon, 7 Dec 2015 09:08:05 +0000 (09:08 +0000)]
BaseTools: Fix a bug when apply patches to SEC use the FILE_GUID override
Fix a bug when applying patches to SEC modules that use the FILE_GUID
override. Since a temp dir is used when FILE_GUID override is used, the
INF file path comparisons fail. The fix is to capture the real INF file
path comparisons instead of using the temp dir path to the INF.
Yonghong Zhu [Mon, 7 Dec 2015 09:04:39 +0000 (09:04 +0000)]
BaseTools: Enhance GenFv Tool to report error message
When two vtf files in one FV image, no FV file can be generated, but it
report the stack trace info. so we enhance the tool to report error
message directly but not the stack trace info.
Yonghong Zhu [Mon, 7 Dec 2015 08:29:10 +0000 (08:29 +0000)]
BaseTools: Enhance GenFv Tool to report error message
When two vtf files in one FV image, no FV file can be generated, but it
report the stack trace info. so we enhance the tool to report error
message directly but not the stack trace info.
Yonghong Zhu [Mon, 7 Dec 2015 08:27:53 +0000 (08:27 +0000)]
BaseTools: Add support for INF statement in FD region
FD region today can be file or data, but not a patched image.Add support
for an INF statement in an FD region, so the binary from the INF can be
patched prior to being added to the FD region.
Ard Biesheuvel [Mon, 7 Dec 2015 06:33:27 +0000 (06:33 +0000)]
CryptoPkg: remove global variable 'timeval' from OpenSslSupport.h
The header file OpenSslSupport.h not only defines a type 'struct timeval'
but also defines a global variable 'timeval' of that type. The RVCT
compiler does not merge this definition into a common symbol, resulting
in duplicate definition errors in the final link. So remove the
variable definition.
Chao Zhang [Mon, 7 Dec 2015 06:20:36 +0000 (06:20 +0000)]
SecurityPkg: SecureBootConfigDxe: SecureBoot UI for Customized SecureBoot Mode
Add SecureBoot UI support for Customized SecureBoot Mode transition according to Mantis 1263. User can do secure boot mode transition through UI.
https://mantis.uefi.org/mantis/view.php?id=1263
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Zeng Star <star.zeng@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19134 6f19259b-4bc3-4df7-8a09-765794883524
Implement Customized SecureBoot Mode transition logic according to Mantis 1263, including AuditMode/DeployedMode/PK update management.
Also implement image verification logic in AuditMode. Image Certificate & Hash are recorded to EFI Image Execution Table.
https://mantis.uefi.org/mantis/view.php?id=1263
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Zeng Star <star.zeng@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19133 6f19259b-4bc3-4df7-8a09-765794883524
Add gEdkiiSecureBootModeGuid definition for Enable Secure Boot feature defined in
UEFI2.5 Mantis 1263. It is a private variable GUID.
https://mantis.uefi.org/mantis/view.php?id=1263
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Zeng Star <star.zeng@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19132 6f19259b-4bc3-4df7-8a09-765794883524
Chao Zhang [Mon, 7 Dec 2015 06:15:49 +0000 (06:15 +0000)]
MdeModulePkg: VarCheckUefiLib: Add DeployedMode/AuditMode var check logic
DeployedMode & AuditMode are UINT8 Global variable according to Enable Secure Boot feature defined in UEFI2.5 Mantis 1263. Add them to var check list.
https://mantis.uefi.org/mantis/view.php?id=1263
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Zeng Star <star.zeng@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19131 6f19259b-4bc3-4df7-8a09-765794883524
If the assert happens in a library, then it's hard to determine which module
using that library is generating that assert. Use gEfiCallerBaseName in
DebugAssert to display the module name.
In V2: Updated patch to use CopyMem instead of AsciiSPrint.
If the assert happens in a library, then it's hard to determine which module
using that library is generating that assert. Use gEfiCallerBaseName in
DebugAssert to display the module name.
V2: Updated code to use copy mem and ModuleNameSize calculation.
If the assert happens in a library, then it's hard to determine which
module using that library is generating that assert. Use gEfiCallerBaseName
in DebugAssert to display the module name.
Shannon Zhao [Fri, 4 Dec 2015 16:17:12 +0000 (16:17 +0000)]
ArmVirtPkg: ArmVirtPlatformLib: find the lowest memory node
While QEMU NUMA support on ARM will introduce more than one /memory node
in the device tree, it needs to find the lowest one and set
PcdSystemMemorySize with the actual size of this memory node.
Liming Gao [Fri, 4 Dec 2015 03:15:08 +0000 (03:15 +0000)]
MdeModulePkg: Fix VS2015 warning C4311 & C4312 in RegularExpressionDxe
warning C4311: pointer truncation from 'void *' to 'unsigned long'
warning C4312: conversion from 'unsigned long' to 'void *' of greater size
Update code to convert type to UINTN first, then convert it to other type.
Ard Biesheuvel [Thu, 3 Dec 2015 08:51:36 +0000 (08:51 +0000)]
ArmVirtPkg: use explicit KERNEL_BLOB_TYPE cast
The ARM RVCT compiler does not allow implicit casts between enumerated
types and integer types. In this particular case, the STUB_FILE::Position
member is overloaded as a KERNEL_BLOB_TYPE identifier, so it does not
hurt to make that cast explicit.
Eugene Cohen [Wed, 2 Dec 2015 16:23:20 +0000 (16:23 +0000)]
ArmPkg RVCT: add asm macro combining EXPORT, AREA and label definition
In response to Leif's request earlier, this adds a new RVCT assembler
macro to centralize the exporting of assembly functions including the
EXPORT directive (so the linker can see it), the AREA directive (so
it's in its own section for code size reasons) and the function label
itself.
Jeff Fan [Wed, 2 Dec 2015 00:43:45 +0000 (00:43 +0000)]
UefiCpuPkg/CpuMpPei: Save/Restore CRx/DRx register for APs waking up
PeiStartupAllAPs()/PeiStartupThisAP() will send INIT-SIPI-SIPI to wakeup APs to
execute AP function. However, some registers will be reset after APs received
INIT IPI. We need to restore some registers (For example, CRx/DRx) manually
after APs wakeup.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19089 6f19259b-4bc3-4df7-8a09-765794883524
Add CPU_VOLATILE_REGISTERS definitions for CRx and DRx required to be restored
after APs received INIT IPI.
Add worker functions SaveVolatileRegisters()/RestoreVolatileRegisters() used to
save/restore CRx and DRx. It also check if Debugging Extensions supported or
not.
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19086 6f19259b-4bc3-4df7-8a09-765794883524
Eugene Cohen [Tue, 1 Dec 2015 18:39:29 +0000 (18:39 +0000)]
ArmPkg: Convert whole-cache InvalidateInstructionCache to just ASSERT
In SVN 18756 ("disallow whole D-cache maintenance operations")
InvalidateInstructionCache was modified to remove the full data cache
clean but left the full instruction cache invalidate. The change was
made to address issues in the set/way clean methodology but the
resulting code could lead someone to a painful debug. If a component
called this function, the proper code would not be flushed to the PoU,
since the intent of this function is not only to invalidate the I-cache
but to provide coherency after code loading / modification. This change
simply places an ASSERT(FALSE) in this function to avoid this hazard.
MdeModulePkg/NvmExpressDxe: Fix wrong logic in GetControllerName()
NvmExpressComponentNameGetControllerName returns EFI_UNSUPPORTED if
child handle is passed. gEfiNvmExpressPassThruProtocolGuid needs to
be passed to EfiTestChildHandle instead of gEfiPciIoProtocolGuid.
Laszlo Ersek [Mon, 30 Nov 2015 23:36:31 +0000 (23:36 +0000)]
OvmfPkg: replace README fine print about X64 SMM S3 with PlatformPei check
At the moment, the "UefiCpuPkg/Universal/Acpi/S3Resume2Pei" module doesn't
support S3 resume if the platform has SMM enabled and the PEI phase is
built for X64. We document this in the README, but it is not conspicuous
enough.
Replace the "fine print" in the README with a runtime check in
PlatformPei.
Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19070 6f19259b-4bc3-4df7-8a09-765794883524
Add return status check to fix GCC build failure below.
error: right-hand operand of comma expression has no effect
[-Werror=unused-value]
((_gPcd_BinaryPatch_PcdSerialUseMmio = (Value)), RETURN_SUCCESS)
error: right-hand operand of comma expression has no effect
[-Werror=unused-value]
((_gPcd_BinaryPatch_PcdSerialRegisterBase = (Value)), RETURN_SUCCESS)
Yao, Jiewen [Mon, 30 Nov 2015 19:57:45 +0000 (19:57 +0000)]
UefiCpuPkg/PiSmmCpu: Always set WP in CR0
So that we can use write-protection for code later.
It is REPOST.
It includes suggestion from Michael Kinney <michael.d.kinney@intel.com>:
- "For IA32 assembly, can we combine into a single OR instruction that
sets both page enable and WP?"
- "For X64, does it make sense to use single OR instruction instead of 2
BTS instructions as well?"
Yao, Jiewen [Mon, 30 Nov 2015 19:57:40 +0000 (19:57 +0000)]
UefiCpuPkg/PiSmmCpu: Always set RW+P bit for page table by default
So that we can use write-protection for code later.
This is REPOST.
It includes the bug fix from "Paolo Bonzini" <pbonzini@redhat.com>:
Title: fix generation of 32-bit PAE page tables
"Bits 1 and 2 are reserved in 32-bit PAE Page Directory Pointer Table
Entries (PDPTEs); see Table 4-8 in the SDM. With VMX extended page
tables, the processor notices and fails the VM entry as soon as CR0.PG
is set to 1."
And thanks "Laszlo Ersek" <lersek@redhat.com> to validate the fix.
Laszlo Ersek [Mon, 30 Nov 2015 18:49:03 +0000 (18:49 +0000)]
OvmfPkg: pull in SMM-based variable driver stack
When -D SMM_REQUIRE is given, replace both
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and
- OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
with
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf.
The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and
the rest:
- the privileged half of the variable driver, VariableSmm,
- the fault tolerant write driver, FaultTolerantWriteSmm,
- and the FVB driver, FvbServicesSmm,
work in SMM purely.
We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the
authenticated VariableSmm driver's sake.
Laszlo Ersek [Mon, 30 Nov 2015 18:48:59 +0000 (18:48 +0000)]
OvmfPkg: consolidate variable driver stack in DSC and FDF files
The following modules constitute the variable driver stack:
- QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime
alternatives for providing the Firmware Volume Block(2) Protocol,
dependent on qemu pflash presence,
- FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol,
- MdeModulePkg/Universal/Variable/RuntimeDxe, independently of
-D SECURE_BOOT_ENABLE, providing the Variable and Variable Write
Architectural Protocols.
Let's move these drivers closer to each other in the DSC and FDF files, so
that we can switch the variable driver stack to SMM with more local
changes.
Laszlo Ersek [Mon, 30 Nov 2015 18:48:46 +0000 (18:48 +0000)]
OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE
At this point we can enable building PiSmmCpuDxeSmm.
CPU specific features, like SMRR detection, and functions that are used to
initialize SMM and process SMIs, are abstracted through the
SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our
own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with
QEMU's and KVM's 64-bit state save map format, which follows the
definition from AMD's programmer manual.
SmmCpuPlatformHookLib provides platform specific functions that are used
to initialize SMM and process SMIs. Resolve it to the one Null instance
provided by UefiCpuPkg, which is expected to work for most platforms.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[pbonzini@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own
instance]
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19061 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Mon, 30 Nov 2015 18:46:55 +0000 (18:46 +0000)]
OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRE
The PiSmmCpuDxeSmm driver from UefiCpuPkg depends on the ACPI_CPU_DATA
structure -- created by a platform- and CPU-specific driver -- in order to
support ACPI S3. The address of this structure is communicated through the
dynamic PCD PcdCpuS3DataAddress.
The "UefiCpuPkg/Include/AcpiCpuData.h" header file documents the fields of
this structure in detail.
The simple/generic "UefiCpuPkg/CpuS3DataDxe" driver creates and populates
the structure in a conformant way, and it co-operates well with
PiSmmCpuDxeSmm, for OVMF's purposes.
PlatformBdsLib CpuS3DataDxe PiSmmCpuDxeSmm S3Resume2Pei
(DXE_DRIVER) (DXE_DRIVER) (DXE_SMM_DRIVER) (PEIM)
-------------- --------------- ---------------- --------------
normal collects data
boot except MTRR
settings into
ACPI_CPU_DATA
sets
PcdCpuS3Da...
signals
End-of-Dxe
|
+----------> collects MTRR
settings into
ACPI_CPU_DATA
Laszlo Ersek [Mon, 30 Nov 2015 18:46:50 +0000 (18:46 +0000)]
OvmfPkg: any AP in SMM should not wait for the BSP for more than 100 ms
This patch complements the previous one, "OvmfPkg: use relaxed AP SMM
synchronization mode". While that patch focuses on the case when the SMI
is raised synchronously by the BSP, on the BSP:
Namely, in APHandler() the AP waits for the BSP to enter SMM regardless of
PcdCpuSmmSyncMode, for PcdCpuSmmApSyncTimeout microseconds (the default
value is 1 second). If the BSP doesn't show up in SMM within that
interval, then the AP brings it in with a directed SMI, and waits for the
BSP again for PcdCpuSmmApSyncTimeout microseconds.
Although during boot services, SmmControl2DxeTrigger() is only called by
the BSP, at runtime the OS can invoke runtime services from an AP (it can
even be forced with "taskset -c 1 efibootmgr"). Because on QEMU
SmmControl2DxeTrigger() only raises the SMI for the calling processor (BSP
and AP alike), the first interval above times out invariably in such cases
-- the BSP never shows up before the AP calls it in.
In order to mitigate the performance penalty, decrease
PcdCpuSmmApSyncTimeout to one tenth of its default value: 100 ms. (For
comparison, Vlv2TbltDevicePkg sets 1 ms.)
NOTE: once QEMU becomes capable of synchronous broadcast SMIs, this patch
and the previous one ("OvmfPkg: use relaxed AP SMM synchronization mode")
should be reverted, and SmmControl2DxeTrigger() should be adjusted
instead.
Cc: Paolo Bonzini <pbonzini@redhat.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: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19059 6f19259b-4bc3-4df7-8a09-765794883524
Paolo Bonzini [Mon, 30 Nov 2015 18:46:46 +0000 (18:46 +0000)]
OvmfPkg: use relaxed AP SMM synchronization mode
Port 0xb2 on QEMU only sends an SMI to the currently executing processor.
The SMI handler, however, and in particular SmmWaitForApArrival, currently
expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors
rather than just the BSP. Thus all SMM invocations loop for a second (the
default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends
another SMI IPI to the APs.
With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs
because 32-bit machines must reset the MTRRs on each entry to system
management modes (they have no SMRRs). However, our virtual platform
does not have problems with cacheability of SMRAM, so we can use "directed"
SMIs instead. To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode
to 1 (aka SmmCpuSyncModeRelaxedAp). This fixes SMM on multiprocessor virtual
machines.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19058 6f19259b-4bc3-4df7-8a09-765794883524
Paolo Bonzini [Mon, 30 Nov 2015 18:46:42 +0000 (18:46 +0000)]
OvmfPkg: SmmCpuFeaturesLib: customize state save map format
This adjusts the previously introduced state save map access functions, to
account for QEMU and KVM's 64-bit state save map following the AMD spec
rather than the Intel one.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[lersek@redhat.com: reflow commit message, convert patch to CRLF]
Cc: Paolo Bonzini <pbonzini@redhat.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@19057 6f19259b-4bc3-4df7-8a09-765794883524
Paolo Bonzini [Mon, 30 Nov 2015 18:46:37 +0000 (18:46 +0000)]
OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map access
This implementation copies SMRAM state save map access from the
PiSmmCpuDxeSmm module.
The most notable change is:
- dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO
- changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use
the SMM revision id instead of a local variable (which
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM
bit). This accounts for QEMU's implementation of x86_64, which always
uses revision 0x20064 even if the LM bit is zero.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[lersek@redhat.com: reflow commit message & fix typo, convert patch to
CRLF]
Cc: Paolo Bonzini <pbonzini@redhat.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@19056 6f19259b-4bc3-4df7-8a09-765794883524
SMRR, MTRR, and SMM Feature Control support is not needed on a virtual
platform.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: insert space between ASSERT and (), convert to CRLF,
refresh against SVN r18958]
Cc: Paolo Bonzini <pbonzini@redhat.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@19055 6f19259b-4bc3-4df7-8a09-765794883524
Paolo Bonzini [Mon, 30 Nov 2015 18:46:27 +0000 (18:46 +0000)]
OvmfPkg: import SmmCpuFeaturesLib from UefiCpuPkg
The next patches will customize the implementation, but let's start from
the common version to better show the changes.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[lersek@redhat.com: drop UNI file, keep whitespace intact, generate new
FILE_GUID, split off DSC changes, reflow commit message, refresh against
SVN r18958]
Cc: Paolo Bonzini <pbonzini@redhat.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@19054 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Mon, 30 Nov 2015 18:42:35 +0000 (18:42 +0000)]
OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to FALSE
Explanation from Michael Kinney:
This PCD allows a platform to provide PlatformSmmBspElection() in a
platform specific SmmCpuPlatformHookLib instance to decide which CPU
gets elected to be the BSP in each SMI.
The SmmCpuPlatformHookLibNull [instance] always returns EFI_NOT_READY
for that function, which makes the module behave the same as the PCD
being set to FALSE.
The default is TRUE, so the platform lib is always called, so a platform
developer can implement the hook function and does not have to also
change a PCD setting for the hook function to be active.
A platform that wants to eliminate the call to the hook function
[altogether] can set the PCD to FALSE.
So for OVMF, I think it makes sense to set this PCD to FALSE in the DSC
file.
Suggested-by: Michael Kinney <michael.d.kinney@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@19053 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Mon, 30 Nov 2015 18:42:31 +0000 (18:42 +0000)]
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):
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.
Laszlo Ersek [Mon, 30 Nov 2015 18:42:23 +0000 (18:42 +0000)]
OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules
UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the
RegisterCpuInterruptHandler() function specifically) to set up its
specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()).
It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER
modules.
Laszlo Ersek [Mon, 30 Nov 2015 18:42:15 +0000 (18:42 +0000)]
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.
Laszlo Ersek [Mon, 30 Nov 2015 18:42:10 +0000 (18:42 +0000)]
OvmfPkg: PlatformPei: don't allocate fake lockbox if SMM_REQUIRE
Since our fake LockBox must not be selected with -D SMM_REQUIRE (see the
previous patch), it makes sense to set aside memory for it only if -D
SMM_REQUIRE is absent. Modify InitializeRamRegions() accordingly.
This patch completes the -D SMM_REQUIRE-related tweaking of the special
OVMF memory areas.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19047 6f19259b-4bc3-4df7-8a09-765794883524
When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation
must not be used, since it doesn't actually protect data in the LockBox
from the runtime guest OS. Add an according assert to
LockBoxLibInitialize().
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19046 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Mon, 30 Nov 2015 18:42:01 +0000 (18:42 +0000)]
OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE
In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox
protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol
in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe
customizations remain valid (or harmless), said change is invalid when
OVMF is built with -D SMM_REQUIRE and includes the real protocol provider,
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf".
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19045 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Mon, 30 Nov 2015 18:41:56 +0000 (18:41 +0000)]
OvmfPkg: pull in CpuIo2Smm driver
This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends
on in its gEfiDxeSmmReadyToLockProtocolGuid callback
(SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c").
Approached on a higher level, this driver provides the SmmIo member of the
EFI_SMM_SYSTEM_TABLE2 (SMST).