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
|
|
|
|
|
);
|
|
|
|
|
|
2013-12-08 02:36:07 +01:00
|
|
|
EFI_STATUS
|
|
|
|
|
PublishPeiMemory (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2014-02-01 22:22:43 +01:00
|
|
|
UINT32
|
|
|
|
|
GetSystemMemorySizeBelow4gb (
|
|
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
2014-02-01 22:22:48 +01:00
|
|
|
VOID
|
|
|
|
|
InitializeRamRegions (
|
2009-05-27 23:10:18 +02:00
|
|
|
VOID
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
EFI_STATUS
|
|
|
|
|
PeiFvInitialization (
|
|
|
|
|
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;
|
|
|
|
|
|
OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits clear
Assume that we boot OVMF in a QEMU guest with 1025 MB of RAM. The
following assertion will fire:
> ASSERT_EFI_ERROR (Status = Out of Resources)
> ASSERT OvmfPkg/PlatformPei/MemDetect.c(696): !EFI_ERROR (Status)
That's because the range [1025 MB, 4 GB) that we try to mark as
uncacheable with MTRRs has size 3071 MB:
0x1_0000_0000
-0x0_4010_0000
--------------
0x0_BFF0_0000
The integer that stands for the uncacheable area size has 11 (eleven) bits
set to 1. As a result, covering this size requires 11 variable MTRRs (each
MTRR must cover a naturally aligned, power-of-two sized area). But, if we
need more variable MTRRs than the CPU can muster (such as 8), then
MtrrSetMemoryAttribute() fails, and we refuse to continue booting (which
is justified, in itself).
Unfortunately, this is not difficult to trigger, and the error message is
well-hidden from end-users, in the OVMF debug log. The following
mitigation is inspired by SeaBIOS:
Truncate the uncacheable area size to a power-of-two, while keeping the
end fixed at 4 GB. Such an interval can be covered by just one variable
MTRR.
This may leave such an MMIO gap, between the end of low-RAM and the start
of the uncacheable area, that is marked as WB (through the MTRR default).
Raise the base of the 32-bit PCI MMIO aperture accordingly -- the gap will
not be used for anything.
On Q35, the minimal 32-bit PCI MMIO aperture (triggered by RAM size 2815
MB) shrinks from
0xE000_0000 - 0xAFF0_0000 = 769 MB
to
0xE000_0000 - 0xC000_0000 = 512 MB
On i440fx, the minimal 32-bit PCI MMIO aperture (triggered by RAM size
3583 MB) shrinks from
0xFC00_0000 - 0xDFF0_0000 = 449 MB
to
0xFC00_0000 - 0xE000_0000 = 448 MB
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=1814
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-05-03 16:01:48 +02:00
|
|
|
extern UINT32 mQemuUc32Base;
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
#endif // _PLATFORM_PEI_H_INCLUDED_
|
