2009-05-27 23:10:18 +02:00
|
|
|
/** @file
|
|
|
|
|
Platform PEI module include file.
|
|
|
|
|
|
2016-04-21 08:31:55 +02:00
|
|
|
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
|
2019-04-04 01:06:33 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
|
|
#ifndef _PLATFORM_PEI_H_INCLUDED_
|
|
|
|
|
#define _PLATFORM_PEI_H_INCLUDED_
|
|
|
|
|
|
2013-12-08 02:36:15 +01:00
|
|
|
#include <IndustryStandard/E820.h>
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
VOID
|
|
|
|
|
AddIoMemoryBaseSizeHob (
|
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
|
UINT64 MemorySize
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
AddIoMemoryRangeHob (
|
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryLimit
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
AddMemoryBaseSizeHob (
|
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
|
UINT64 MemorySize
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
AddMemoryRangeHob (
|
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryLimit
|
|
|
|
|
);
|
|
|
|
|
|
2011-08-05 17:43:05 +02:00
|
|
|
VOID
|
|
|
|
|
AddReservedMemoryBaseSizeHob (
|
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
2015-11-30 19:41:29 +01:00
|
|
|
UINT64 MemorySize,
|
|
|
|
|
BOOLEAN Cacheable
|
2011-08-05 17:43:05 +02:00
|
|
|
);
|
|
|
|
|
|
2015-06-26 18:09:39 +02:00
|
|
|
VOID
|
|
|
|
|
AddressWidthInitialization (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2017-07-04 12:44:05 +02:00
|
|
|
VOID
|
|
|
|
|
Q35TsegMbytesInitialization (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2019-09-20 14:02:14 +02:00
|
|
|
VOID
|
|
|
|
|
Q35SmramAtDefaultSmbaseInitialization (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2013-12-08 02:36:07 +01:00
|
|
|
EFI_STATUS
|
|
|
|
|
PublishPeiMemory (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2014-02-01 22:22:43 +01:00
|
|
|
UINT32
|
|
|
|
|
GetSystemMemorySizeBelow4gb (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
OvmfPkg/PlatformPei: set 32-bit UC area at PciBase / PciExBarBase (pc/q35)
(This is a replacement for commit 39b9a5ffe661 ("OvmfPkg/PlatformPei: fix
MTRR for low-RAM sizes that have many bits clear", 2019-05-16).)
Reintroduce the same logic as seen in commit 39b9a5ffe661 for the pc
(i440fx) board type.
For q35, the same approach doesn't work any longer, given that (a) we'd
like to keep the PCIEXBAR in the platform DSC a fixed-at-build PCD, and
(b) QEMU expects the PCIEXBAR to reside at a lower address than the 32-bit
PCI MMIO aperture.
Therefore, introduce a helper function for determining the 32-bit
"uncacheable" (MMIO) area base address:
- On q35, this function behaves statically. Furthermore, the MTRR setup
exploits that the range [0xB000_0000, 0xFFFF_FFFF] can be marked UC with
just two variable MTRRs (one at 0xB000_0000 (size 256MB), another at
0xC000_0000 (size 1GB)).
- On pc (i440fx), the function behaves dynamically, implementing the same
logic as commit 39b9a5ffe661 did. The PciBase value is adjusted to the
value calculated, similarly to commit 39b9a5ffe661. A further
simplification is that we show that the UC32 area size truncation to a
whole power of two automatically guarantees a >=2GB base address.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-05-29 14:49:55 +02:00
|
|
|
VOID
|
|
|
|
|
QemuUc32BaseInitialization (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2014-02-01 22:22:48 +01:00
|
|
|
VOID
|
|
|
|
|
InitializeRamRegions (
|
2009-05-27 23:10:18 +02:00
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
PeiFvInitialization (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Secure SMM Communication
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf
--^--
bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call
for action", recommend enabling the (adaptive) Memory Type Information
feature.
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
--^--
figure#6 describes the Memory Type Information feature in detail; namely
as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE
Core, and BDS.
Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling
the Secure SMM Communication recommendation.
In the longer term, OVMF should install the WSMT ACPI table, and this
patch contributes to that.
Notes:
- the step in figure#6 where the UEFI variable is copied into the HOB is
covered by the DXE IPL PEIM, in the DxeLoadCore() function,
- "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC
default TRUE value, because both whitepapers indicate that BDS needs to
reset the system if the Memory Type Information changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-6-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
2020-03-10 23:27:39 +01:00
|
|
|
VOID
|
|
|
|
|
MemTypeInfoInitialization (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2016-07-07 15:02:11 +02:00
|
|
|
VOID
|
|
|
|
|
InstallFeatureControlCallback (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2018-10-02 14:17:25 +02:00
|
|
|
VOID
|
|
|
|
|
InstallClearCacheCallback (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2011-08-05 17:43:05 +02:00
|
|
|
EFI_STATUS
|
|
|
|
|
InitializeXen (
|
2014-02-01 22:22:19 +01:00
|
|
|
VOID
|
2013-12-08 02:36:00 +01:00
|
|
|
);
|
|
|
|
|
|
2014-02-01 22:22:19 +01:00
|
|
|
BOOLEAN
|
2013-12-08 02:36:00 +01:00
|
|
|
XenDetect (
|
2011-08-05 17:43:05 +02:00
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabled
Secure Encrypted Virtualization (SEV) guest VMs have the concept of
private and shared memory. Private memory is encrypted with the
guest-specific key, while shared memory may be encrypted with hypervisor
key. Certain types of memory (namely instruction pages and guest page
tables) are always treated as private memory by the hardware.
For data memory, SEV guest VMs can choose which pages they would like
to be private. The choice is done using the standard CPU page tables
using the C-bit. When building the initial page table we mark all the
memory as private.
The patch sets the memory encryption PCD. The PCD is consumed by the
following edk2 modules, which manipulate page tables:
- PEI phase modules: CapsulePei, DxeIplPeim, S3Resume2Pei.
CapsulePei is not used by OVMF. DxeIplPeim consumes the PCD at the
end of the PEI phase, when it builds the initial page tables for the
DXE core / DXE phase. S3Resume2Pei does not consume the PCD in its
entry point function, only when DxeIplPeim branches to the S3 resume
path at the end of the PEI phase, and calls S3Resume2Pei's
EFI_PEI_S3_RESUME2_PPI.S3RestoreConfig2() member function.
Therefore it is safe to set the PCD for these modules in PlatformPei.
- DXE phase modules: BootScriptExecutorDxe, CpuDxe, PiSmmCpuDxeSmm.
They are all dispatched after the PEI phase, so setting the PCD for
them in PlatformPei is safe. (BootScriptExecutorDxe is launched "for
real" in the PEI phase during S3 resume, but it caches the PCD into a
static variable when its entry point is originally invoked in DXE.)
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:25:48 +02:00
|
|
|
VOID
|
|
|
|
|
AmdSevInitialize (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2014-02-01 22:22:12 +01:00
|
|
|
extern BOOLEAN mXen;
|
|
|
|
|
|
2014-02-01 22:22:25 +01:00
|
|
|
VOID
|
|
|
|
|
XenPublishRamRegions (
|
|
|
|
|
VOID
|
2013-12-08 02:36:15 +01:00
|
|
|
);
|
|
|
|
|
|
2014-03-04 09:01:40 +01:00
|
|
|
extern EFI_BOOT_MODE mBootMode;
|
|
|
|
|
|
2014-03-04 09:01:58 +01:00
|
|
|
extern BOOLEAN mS3Supported;
|
|
|
|
|
|
2015-06-26 18:09:39 +02:00
|
|
|
extern UINT8 mPhysMemAddressWidth;
|
|
|
|
|
|
2016-11-24 15:18:44 +01:00
|
|
|
extern UINT32 mMaxCpuCount;
|
|
|
|
|
|
2017-07-04 14:50:43 +02:00
|
|
|
extern UINT16 mHostBridgeDevId;
|
|
|
|
|
|
2019-09-20 14:02:14 +02:00
|
|
|
extern BOOLEAN mQ35SmramAtDefaultSmbase;
|
|
|
|
|
|
OvmfPkg/PlatformPei: set 32-bit UC area at PciBase / PciExBarBase (pc/q35)
(This is a replacement for commit 39b9a5ffe661 ("OvmfPkg/PlatformPei: fix
MTRR for low-RAM sizes that have many bits clear", 2019-05-16).)
Reintroduce the same logic as seen in commit 39b9a5ffe661 for the pc
(i440fx) board type.
For q35, the same approach doesn't work any longer, given that (a) we'd
like to keep the PCIEXBAR in the platform DSC a fixed-at-build PCD, and
(b) QEMU expects the PCIEXBAR to reside at a lower address than the 32-bit
PCI MMIO aperture.
Therefore, introduce a helper function for determining the 32-bit
"uncacheable" (MMIO) area base address:
- On q35, this function behaves statically. Furthermore, the MTRR setup
exploits that the range [0xB000_0000, 0xFFFF_FFFF] can be marked UC with
just two variable MTRRs (one at 0xB000_0000 (size 256MB), another at
0xC000_0000 (size 1GB)).
- On pc (i440fx), the function behaves dynamically, implementing the same
logic as commit 39b9a5ffe661 did. The PciBase value is adjusted to the
value calculated, similarly to commit 39b9a5ffe661. A further
simplification is that we show that the UC32 area size truncation to a
whole power of two automatically guarantees a >=2GB base address.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-05-29 14:49:55 +02:00
|
|
|
extern UINT32 mQemuUc32Base;
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
#endif // _PLATFORM_PEI_H_INCLUDED_
|
