Laszlo Ersek [Mon, 30 Nov 2015 18:41:48 +0000 (18:41 +0000)]
OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER
The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the
SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the
mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function
[MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c].
Laszlo Ersek [Mon, 30 Nov 2015 18:41:43 +0000 (18:41 +0000)]
OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXE
The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which
is a thin wrapper around "OvmfPkg/SmmAccess/SmramInternal.c" that was
added in the previous patch) provides that protocol.
Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore
our MODULE_TYPE is not DXE_RUNTIME_DRIVER.
Laszlo Ersek [Mon, 30 Nov 2015 18:41:38 +0000 (18:41 +0000)]
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
Laszlo Ersek [Mon, 30 Nov 2015 18:41:33 +0000 (18:41 +0000)]
OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set
PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:
- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
so that it ends with the RAM below 4GB,
- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
created for the RAM below 4GB; plus MTRR attributes are set
(independently of S3 vs. normal boot)
- MemMapInitialization(): an MMIO resource descriptor HOB is created for
PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
2GB).
The first two of these is adjusted for the configured TSEG size, if
PcdSmmSmramRequire is set:
- In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.
- In QemuInitializeRam(), we must keep the DXE out of TSEG.
One idea would be to simply trim the [1MB .. LowerMemorySize] memory
resource descriptor HOB, leaving a hole for TSEG in the memory space
map.
The SMM IPL will however want to massage the caching attributes of the
SMRAM range that it loads the SMM core into, with
gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
instead of trimming this range, split the TSEG area off, and report it
as a cacheable reserved memory resource.
Finally, since reserved memory can be allocated too, pre-allocate TSEG
in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
this step alone does not suffice without the resource descriptor HOB
trickery: if we omit that, then the DXE IPL PEIM fails to load and start
the DXE core.)
- In MemMapInitialization(), the start of the PCI MMIO range is not
affected.
We choose the largest option (8MB) for the default TSEG size. Michael
Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm consumes
SMRAM proportionally to the number of CPUs. From the three options
available, he reported that 8MB was both necessary and sufficient for the
SMBASE relocation to succeed with 255 CPUs:
Laszlo Ersek [Mon, 30 Nov 2015 18:41:29 +0000 (18:41 +0000)]
OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob()
AddReservedMemoryBaseSizeHob() should be able to set the same resource
attributes for reserved memory as AddMemoryBaseSizeHob() sets for system
memory. Add a new parameter called "Cacheable" to
AddReservedMemoryBaseSizeHob(), and set it to FALSE in the only caller we
have at the moment.
Laszlo Ersek [Mon, 30 Nov 2015 18:41:24 +0000 (18:41 +0000)]
OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set
If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
not trusted and we should defend against it tampering with the firmware's
data.
One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
decompressed on the first boot by SEC, then the OS preserves it across S3
suspend-resume cycles; at S3 resume SEC just reuses the originally
decompressed PEIFV.
However, if we don't trust the OS, then SEC must decompress PEIFV from the
pristine flash every time, lest we execute OS-injected code or work with
OS-injected data.
Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV;
the decompression brings DXEFV with itself, plus it uses a temporary
output buffer and a scratch buffer too, which even reach above the end of
the finally installed DXEFV. For this reason we must keep away a
non-malicious OS from DXEFV too, plus the memory up to
PcdOvmfDecomprScratchEnd.
The delay introduced by the LZMA decompression on S3 resume is negligible.
If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE
(from the DEC file), and then this patch has no effect (not counting some
changed debug messages).
If QEMU doesn't support S3 (or the user disabled it on the QEMU command
line), then this patch has no effect also.
Laszlo Ersek [Mon, 30 Nov 2015 18:41:20 +0000 (18:41 +0000)]
OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer
The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).
DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.
Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.
Laszlo Ersek [Mon, 30 Nov 2015 18:41:14 +0000 (18:41 +0000)]
OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table
BaseExtractGuidedSectionLib uses a table at the static physical address
PcdGuidedExtractHandlerTableAddress, and modules that are linked against
BaseExtractGuidedSectionLib are expected to work together on that table.
Namely, some modules can register handlers for GUIDed sections, some other
modules can decode such sections with the pre-registered handlers. The
table carries persistent information between these modules.
BaseExtractGuidedSectionLib checks a table signature whenever it is used
(by whichever module that is linked against it), and at the first use
(identified by a signature mismatch) it initializes the table.
One of the module types that BaseExtractGuidedSectionLib can be used with
is SEC, if the SEC module in question runs with the platform's RAM already
available.
In such cases the question emerges whether the initial contents of the RAM
(ie. contents that predate the very first signature check) can be trusted.
Normally RAM starts out with all zeroes (leading to a signature mismatch
on the first check); however a malicious runtime OS can populate the area
with some payload, then force a warm platform reset or an S3
suspend-and-resume. In such cases the signature check in the SEC module
might not fire, and ExtractGuidedSectionDecode() might run code injected
by the runtime OS, as part of SEC (ie. with high privileges).
Therefore we clear the handler table in SEC.
See also git commit ad43bc6b2e (SVN rev 15433) -- this patch secures the
(d) and (e) code paths examined in that commit. Furthermore, a
non-malicious runtime OS will observe no change in behavior; see case (c)
in said commit.
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>
[michael.d.kinney@intel.com: prevent VS20xx loop intrinsic with volatile]
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19035 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel [Mon, 30 Nov 2015 08:57:26 +0000 (08:57 +0000)]
CryptoPkg/OpensslLib: add softfloat dependency for ARM
UEFI on 32-bit ARM does not allow the use of hardware floating point,
so in order to be able to run OpenSslLib, we need to fulfil its
floating point arithmetic dependencies using a software library.
Ard Biesheuvel [Mon, 30 Nov 2015 08:57:12 +0000 (08:57 +0000)]
ArmVirtPkg: add secure boot support to 32-bit ARM targets
Building the 32-bit ARM targets with secure boot enabled requires
a library resolution for the ArmSoftfloatLib dependency of
OpenSslLib. So provide one.
Ard Biesheuvel [Mon, 30 Nov 2015 08:57:03 +0000 (08:57 +0000)]
ArmPkg/ArmSoftFloatLib: add support for RVCT
The ARM softfloat library in ArmSoftfloatLib currently does not build
under RVCT, simply because the code includes system header files that
RVCT does not provide. However, nothing exported by those include files
is actually used by the library when built in SOFTFLOAT_FOR_GCC mode,
so we can just drop all of them.
Ard Biesheuvel [Mon, 30 Nov 2015 08:56:52 +0000 (08:56 +0000)]
ArmPkg: factor out softfloat support from StdLib/LibC/SoftFloat
In order to support software floating point in the context of
DXE drivers etc, this factors out the core ARM softfloat support
into a separate library.
Yonghong Zhu [Mon, 30 Nov 2015 03:43:25 +0000 (03:43 +0000)]
BaseTools/toolsetup.bat: fixed the error when the path contains space
We have a new simple and effective method to resolve the original issue
that the PATH env's update error when the path contains space, so this
patch remove the last check in and use the new method to fix the original
issue.
Yonghong Zhu [Mon, 30 Nov 2015 03:40:37 +0000 (03:40 +0000)]
BaseTools: Add build error detection for Dynamic PCD name conflict
when multiple Dynamic PCD have different token space guid but same PCD
name, it is difficult for user to check why the generated autogen.c and
autogen.h are not consistent. so we add a check before generating
autogen.c and report error directly that user can know what happened
immediately.
Yonghong Zhu [Mon, 30 Nov 2015 03:36:50 +0000 (03:36 +0000)]
BaseTools: Add a VPD report subsection of FLASH to the Report
Build Spec already added a VPD report subsection of FLASH to the Report
chapter, it provide a simple way for user to determine where the VPD
region and VPD PCDs are located in the fd file.
Ruiyu Ni [Mon, 30 Nov 2015 03:08:49 +0000 (03:08 +0000)]
MdeModulePkg/BDS: Do not pass unnecessary option to boot option
BDS puts a special GUID in boot option optional data for
auto-discovered boot option. But when launching that boot
option, the BDS core unconditionally pass the special GUID
to the executable.
A good written application/OS loader can ignore the unexpected
parameters, but BDS core should still avoid passing the
unnecessary GUID.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19007 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel [Fri, 27 Nov 2015 17:11:03 +0000 (17:11 +0000)]
ArmPkg: remove SetPrimaryStack and InitializePrimaryStack macros
The SetPrimaryStack and InitializePrimaryStack macros are no longer
used now that we removed support for ArmPlatformGlobalVariableLib.
So remove the various versions of them.
Ard Biesheuvel [Fri, 27 Nov 2015 17:10:28 +0000 (17:10 +0000)]
ArmPlatformPkg: remove ArmGlobalVariable PCD, GUID and PPI definitions
Now that we removed all references to the ArmGlobalVariable definitions
in the various lowlevel PrePi and PrePeiCore init routines, and removed
the PPI and HOB references from PlatformPeim, it is time to say goodbye
to ArmGlobalVariable. So remove the includes and the .DEC declarations.
Ard Biesheuvel [Fri, 27 Nov 2015 17:07:43 +0000 (17:07 +0000)]
ArmPlatformPkg/Sec: remove global variable allocation from lowlevel init
Now that we dropped all ArmPlatformGlobalVariableLib dependencies,
there is no longer a need to allocate and clear out the global
variable region in the Sec init code. So remove it.
Ard Biesheuvel [Fri, 27 Nov 2015 17:07:31 +0000 (17:07 +0000)]
ArmPlatformPkg/PrePeiCore: remove global variable allocation from lowlevel init
Now that we dropped all ArmPlatformGlobalVariableLib dependencies,
there is no longer a need to allocate and clear out the global
variable region in the PrePeiCore init code. So remove it.
Now that we dropped all ArmPlatformGlobalVariableLib dependencies,
there is no longer a need to query the ArmGlobalVariable PPI and install
the ArmGlobalVariable HOB. So remove it.
Ard Biesheuvel [Fri, 27 Nov 2015 17:07:06 +0000 (17:07 +0000)]
ArmPlatformPkg/PrePi: remove global variable allocation from lowlevel init
Now that we dropped all ArmPlatformGlobalVariableLib dependencies,
there is no longer a need to allocate and clear out the global
variable region in the PrePi init code. So remove it.
Ard Biesheuvel [Fri, 27 Nov 2015 17:06:48 +0000 (17:06 +0000)]
ArmVirtPkg/PrePi: remove global variable allocation from lowlevel init
Now that we dropped all ArmPlatformGlobalVariableLib dependencies,
there is no longer a need to allocate and clear out the global
variable region in the PrePi init code. So remove it.
Ard Biesheuvel [Fri, 27 Nov 2015 17:06:37 +0000 (17:06 +0000)]
ArmPlatformPkg: remove all ArmPlatformGlobalVariableLib implementations
This removes the SEC, PEI and DXE variants of ArmPlatformGlobalVariableLib,
which is no longer used, and should not be used since it violates the PI
spec.
This removes the PeiServicesTablePointerLib implementation under
ArmPlatformPkg that violates the PI spec, and hence should not be
used. Instead, the implementation that resides under ArmPkg should
be used.
Ard Biesheuvel [Fri, 27 Nov 2015 17:05:59 +0000 (17:05 +0000)]
ArmPlatformPkg: move to ArmPkg version of PeiServicesTablePointerLib
As pointed out by Eugene, the ArmPlatformPkg implementation of
PeiServicesTablePointerLib violates the PI sec, since it uses
ArmPlatformGlobalVariableLib to store the PEI services table pointer
rather than the thread ID cpu registers as the spec requires.
So instead, move to the ArmPkg version of this library, which does
adhere to the PI spec.
Ard Biesheuvel [Fri, 27 Nov 2015 17:05:47 +0000 (17:05 +0000)]
ArmVirtPkg: drop ArmPlatformGlobalVariableLib dependency
Now that all PeiServicesTablePointerLib and PrePiHobListPointerLib
library dependencies in both ArmVirtQemu and ArmVirtXen are satisfied
by implementations that do not depend on ArmPlatformGlobalVariableLib,
we can remove all mention of it from the various .dsc files.
Ard Biesheuvel [Fri, 27 Nov 2015 17:05:36 +0000 (17:05 +0000)]
ArmVirtPkg/ArmVirtQemu: move to ArmPkg version of PeiServicesTablePointerLib
As pointed out by Eugene, the ArmPlatformPkg implementation of
PeiServicesTablePointerLib violates the PI sec, since it uses
ArmPlatformGlobalVariableLib to store the PEI services table pointer
rather than the thread ID cpu registers as the spec requires.
So instead, move to the ArmPkg version of this library, which does
adhere to the PI spec.
Ard Biesheuvel [Fri, 27 Nov 2015 17:04:59 +0000 (17:04 +0000)]
ArmPlatformPkg/PrePiHobListPointerLib: use thread ID register
This updates the PrePiHobListPointerLib implementation in ArmPlatformPkg
to move away from ArmPlatformGlobalVariableLib and instead use the thread
ID CPU registers (TPIDRURW and TPIDR_EL0 for v7 and v8, respectively)
for storing the HobList pointer.
Since PrePiHobListPointerLib is specific to PrePi (where PEI core is skipped)
we can share these registers with the PEI services table pointer. By the
same reasoning, the PEI services table pointer and the HobList pointer
already shared the same offset in the ArmPlatformGlobalVariable array.
Yao, Jiewen [Fri, 27 Nov 2015 13:48:12 +0000 (13:48 +0000)]
UefiCpuPkg/PiSmmCpu: Update function call for 2 new APIs.
All page table allocation will use AllocatePageTableMemory().
Add SmmCpuFeaturesCompleteSmmReadyToLock() to PerformRemainingTasks()
and PerformPreTasks().
Yao, Jiewen [Fri, 27 Nov 2015 13:48:03 +0000 (13:48 +0000)]
UefiCpuPkg/PiSmmCpu: Add 2 APIs in SmmCpuFeaturesLib.
SmmCpuFeaturesCompleteSmmReadyToLock() is a hook point to
allow CPU specific code to do more registers setting after
the gEfiSmmReadyToLockProtocolGuid notification is completely
processed.
SmmCpuFeaturesAllocatePageTableMemory() is an API to allow
CPU to allocate a specific region for storing page tables.
Ard Biesheuvel [Fri, 27 Nov 2015 09:24:27 +0000 (09:24 +0000)]
ArmPlatformPkg/PrePeiCore: add missing entries to AArch64 vector table
The PrePeiCore vector table for AArch64 mode is only half populated.
However unlikely, if exceptions from lower exception levels are ever
taken, they should be reported correctly, rather than causing a
recursive undefined instruction fault on the zero padding that was
introduced by commit SVN r18904 ("ArmPkg/ArmPlatformPkg: position
vectors relative to base"). So add the missing entries, and wire
them up to the default handler.
Star Zeng [Thu, 26 Nov 2015 08:52:12 +0000 (08:52 +0000)]
ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
Beyond just changing the directly related lines in the FDF and DSC files,
we have to adapt the EarlyFdtPL011SerialPortLib and FdtPL011SerialPortLib
instances as well, in the same patch. This is because the EmbeddedPkg
driver expects the SerialPortSetAttributes(),
SerialPortSetControl() and SerialPortGetControl() functions from
SerialPortExtLib, while the MdeModulePkg driver expects them from
SerialPortLib itself.
We cannot implement these functions in ArmVirtPkg's SerialPortLib
instances *before* flipping the driver, because it would cause double
function definitions in the EmbeddedPkg driver. We also can't implement
the functions *after* flipping the driver, because it would cause
unresolved function references in the MdeModulePkg driver. Therefore
we have to implement the functions simultaneously with the driver
replacement.
Star Zeng [Thu, 26 Nov 2015 08:49:26 +0000 (08:49 +0000)]
CorebootPayloadPkg: Use SerialDxe in MdeModulePkg
1. Update fdf and dsc to use SerialDxe in MdeModulePkg.
2. Separate the code that gets SerialRegBase and SerialRegAccessType
by CbParseLib from CorebootPayloadPkg/Library/SerialPortLib to
PlatformHookLib, and then leverage BaseSerialPortLib16550 in
MdeModulePkg.
3. Remove CorebootPayloadPkg/SerialDxe and
CorebootPayloadPkg/Library/SerialPortLib.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18968 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng [Thu, 26 Nov 2015 08:48:38 +0000 (08:48 +0000)]
EmulatorPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
It is also to add GetControl/SetControl/SetAttributes implementation
for DxeEmuSerialPortLib.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18967 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng [Thu, 26 Nov 2015 08:48:10 +0000 (08:48 +0000)]
MdeModulePkg: Upstream SerialDxe from EmbeddedPkg
This Serial driver layers on top of a Serial Port Library instance
to produce serial IO protocol.
There is also another SerialDxe implementation in CorebootPayloadPkg,
but SerialDxe from EmbeddedPkg should be better that also consumes
the extended interfaces GetControl/SetControl/SetAttributes in
EmbeddedPkg/Include/Library/SerialPortExtLib.h for serial IO protocol.
And the extended interfaces GetControl/SetControl/SetAttributes in
EmbeddedPkg/Include/Library/SerialPortExtLib.h has been upstream to
MdePkg/Include/Library/SerialPortLib.h.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18966 6f19259b-4bc3-4df7-8a09-765794883524
The SerialIo->GetControl() function is not required to set the
Control output parameter on error. Make sure we apply the
EFI_SERIAL_INPUT_BUFFER_EMPTY optimization in
TerminalConInTimerHandler() only if the SerialIo->GetControl()
function call set that bit in the Control variable.
Yao, Jiewen [Thu, 26 Nov 2015 04:12:53 +0000 (04:12 +0000)]
Add 2 APIs in SmmCpuFeaturesLib.
Add NULL func for 2 new APIs in SmmCpuFeaturesLib.
SmmCpuFeaturesCompleteSmmReadyToLock() is a hook point to allow
CPU specific code to do more registers setting after
the gEfiSmmReadyToLockProtocolGuid notification is completely processed.
Add SmmCpuFeaturesCompleteSmmReadyToLock() to PerformRemainingTasks() and PerformPreTasks().
SmmCpuFeaturesAllocatePageTableMemory() is an API to allow
CPU to allocate a specific region for storing page tables.
All page table allocation will use AllocatePageTableMemory().
As of SVN 15115, the PEI core needs a MigratePeiServicesTablePointer function.
Background: The ArmPkg variant of the PeiServicesTablePointerLib implements
the standard PEI Services table retrieval mechanism as defined in the
PI Specification Volume 1 section 5.4.4 using the TPIDRURW registers.
No special action is required on ARM to migrate the PEI Services table
pointer after main memory initialization but a function must be implemented
nonetheless.
Michael Kinney [Wed, 25 Nov 2015 17:01:02 +0000 (17:01 +0000)]
UefiCpuPkg/CpuS3DataDxe: Add module to initialize ACPI_CPU_DATA for S3
This module initializes the ACPI_CPU_DATA structure and registers the
address of this structure in the PcdCpuS3DataAddress PCD. This is a
generic/simple version of this module. It does not provide a machine
check handler or CPU register initialization tables for ACPI S3 resume.
It also only supports the number of CPUs reported by the MP Services
Protocol, so this module does not support hot plug CPUs. This module
can be copied into a CPU specific package and customized if these
additional features are required.
This patch series is in response to the OvmfPkg patch series from
Laszlo Ersek that enables SMM on OVMF. The v4 version of the patch
series from Laszlo includes an OVMF specific CPU module to initialize
the ACPI_CPU_DATA structure.
This proposed patch series replaces the patches listed below.
Yao, Jiewen [Wed, 25 Nov 2015 08:40:49 +0000 (08:40 +0000)]
Install LoadedImage protocol for PiSmmCore.
PiSmmCore installs LoadedImage for each SMM driver. However itself is missing.
So we follow DxeCore style, let PiSmmCore installs LoadedImage protocol for itself,
then the SMM image information is complete.
Yao, Jiewen [Wed, 25 Nov 2015 04:28:46 +0000 (04:28 +0000)]
Move RestoreSmmConfigurationInS3 function to PerformPreTasks().
In this way, we can centralize the silicon configuration in
PerformRemainingTasks()/PerformPreTasks() function.
If there are more features need to be configured, they can put in
PerformRemainingTasks()/PerformPreTasks() only.
Yao, Jiewen [Wed, 25 Nov 2015 04:23:01 +0000 (04:23 +0000)]
Eliminate EFI_IMAGE_MACHINE_TYPE_SUPPORTED.
Move Gdt initialization from InitializeMpServiceData() to CPU Arch specific function.
We create SmmFuncsArch.c for hold CPU specific function, so that
EFI_IMAGE_MACHINE_TYPE_SUPPORTED(EFI_IMAGE_MACHINE_X64) can be removed.
For IA32 version, we always allocate new page for GDT entry, for easy maintenance.
For X64 version, we fixed TssBase in GDT entry to make sure TSS data is correct.
Remove TSS fixup for GDT in ASM file.
Yao, Jiewen [Wed, 25 Nov 2015 04:05:49 +0000 (04:05 +0000)]
Uninstall LoadedImage protocol if SMM driver returns error and is unloaded.
Original code does not uninstall LoadedImage protocol if SMM driver returns error and is unloaded.
It causes a wrong LoadedImage protocol existing in system.
Jeff Fan [Wed, 25 Nov 2015 02:47:59 +0000 (02:47 +0000)]
UefiCpuPkg/CpuMpPei: Enable x2APIC mode on BSP/APs
If x2APIC flag is set, enable x2APIC mode on all APs and BSP. Before we wakeup
APs to enable x2APIC mode, we should wait all APs have finished initialization.
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: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18934 6f19259b-4bc3-4df7-8a09-765794883524
R_ARM_REL32 are relative relocations, so we don't need to do anything
special when performing the ELF to PE/COFF conversion, since our memory
layout is identical between the two binary formats. So just allow them.
Ard Biesheuvel [Tue, 24 Nov 2015 07:48:06 +0000 (07:48 +0000)]
ArmLib/ArmV7Mmu: use 64-bit type for mapping region size
The way the v7 MMU code is invoked by the Xen port is somewhat of
a pathological case, since it describes its physical memory space
using a single cacheable region that covers the entire addressable
range. When clipping this region to the part that is 1:1 addressable,
we end up with a region of exactly 4 GB in size, which just exceeds
the range of the UINT32 variable we use in FillTranslationTable() to
track our progress while populating the page tables. So promote it
to UINT64 instead.
Ard Biesheuvel [Tue, 24 Nov 2015 07:44:41 +0000 (07:44 +0000)]
ArmVirtPkg/ArmVirtPlatformLib: reduce ID map size to GCD region size
The ID mapping routines on virtual platforms simply map the entire
hardware supported physical address space as device memory, and then
punch some holes for regions that need to be mapped cacheable.
On virtual platforms hosted on CPUs that support a large physical
address range, this may result in a lot of overhead, i.e., 4 KB of page
tables for each 512 GB of address space, which quickly adds up (i.e.,
2 MB for the architectural maximum of 48 bits).
Since there may be a platform specific limit to the size of the (I)PA
space that is not reflected by CPU id registers, restrict the range of
the ID mapping to gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize bits.
This makes sense by itself, since we cannot manipulate mappings above
that limit anwyay (because they are not covered by GCD), and it allows
the PCD be set to a lower value by platforms whose (I)PA space is
smaller than the hardware supported maximum.
Ard Biesheuvel [Tue, 24 Nov 2015 07:44:28 +0000 (07:44 +0000)]
ArmVirtPkg/ArmVirtQemu: limit the (I)PA space to 40 bits
KVM uses a fixed size of 40 bits for its intermediate physical address
space, so there is no need to support anything beyond that even if the
host hardware does.
Align to old BDS behavior (IntelFrameworkModulePkg/BDS) to always create
MemoryTypeInfo variable regardless of the PcdResetOnMemoryTypeInformationChange
value.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18926 6f19259b-4bc3-4df7-8a09-765794883524
Dandan Bi [Mon, 23 Nov 2015 09:37:24 +0000 (09:37 +0000)]
MdeModulePkg:Refine the UiApp
Use new created libraries(Boot Manager,Device Manager,Boot Maintenance
Manager) in UiApp.So remove and refine relative code in UiApp.And update
the Nt32Pkg.dsc and MdeModulePkg.dsc.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18924 6f19259b-4bc3-4df7-8a09-765794883524
Heyi Guo [Mon, 23 Nov 2015 07:48:33 +0000 (07:48 +0000)]
ArmPkg: Invalidate cache after allocating UC memory
It is implied that the memory returned from UncachedMemoryAllocationLib
should have cache invalidated. So we invalidate memory range after
changing memory attribute to uncached.
projects / mirror_edk2.git / log