2009-05-27 23:10:18 +02:00
|
|
|
/**@file
|
|
|
|
Platform PEI driver
|
|
|
|
|
2016-04-07 12:19:23 +02:00
|
|
|
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
|
2011-08-05 17:43:05 +02:00
|
|
|
Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
|
|
|
|
|
2010-04-28 14:43:04 +02:00
|
|
|
This program and the accompanying materials
|
2009-05-27 23:10:18 +02:00
|
|
|
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.
|
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
//
|
|
|
|
// The package level header files this module uses
|
|
|
|
//
|
|
|
|
#include <PiPei.h>
|
|
|
|
|
|
|
|
//
|
|
|
|
// The Library classes this module consumes
|
|
|
|
//
|
2015-12-01 00:36:31 +01:00
|
|
|
#include <Library/BaseLib.h>
|
2009-05-27 23:10:18 +02:00
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
#include <Library/HobLib.h>
|
|
|
|
#include <Library/IoLib.h>
|
2009-09-07 22:18:17 +02:00
|
|
|
#include <Library/MemoryAllocationLib.h>
|
|
|
|
#include <Library/PcdLib.h>
|
2009-05-27 23:10:18 +02:00
|
|
|
#include <Library/PciLib.h>
|
|
|
|
#include <Library/PeimEntryPoint.h>
|
2011-03-22 02:55:08 +01:00
|
|
|
#include <Library/PeiServicesLib.h>
|
2014-03-04 09:01:58 +01:00
|
|
|
#include <Library/QemuFwCfgLib.h>
|
2017-02-22 03:47:18 +01:00
|
|
|
#include <Library/QemuFwCfgS3Lib.h>
|
2009-05-27 23:10:18 +02:00
|
|
|
#include <Library/ResourcePublicationLib.h>
|
|
|
|
#include <Guid/MemoryTypeInformation.h>
|
2011-03-22 02:55:08 +01:00
|
|
|
#include <Ppi/MasterBootMode.h>
|
OvmfPkg: enable PIIX4 IO space in the PEI phase
I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 09:19:16 +02:00
|
|
|
#include <IndustryStandard/Pci22.h>
|
2014-11-14 01:37:26 +01:00
|
|
|
#include <OvmfPlatforms.h>
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
#include "Platform.h"
|
2011-01-21 17:50:31 +01:00
|
|
|
#include "Cmos.h"
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
|
|
|
|
{ EfiACPIMemoryNVS, 0x004 },
|
2010-07-16 21:04:41 +02:00
|
|
|
{ EfiACPIReclaimMemory, 0x008 },
|
2010-10-13 09:07:29 +02:00
|
|
|
{ EfiReservedMemoryType, 0x004 },
|
2010-07-16 21:04:41 +02:00
|
|
|
{ EfiRuntimeServicesData, 0x024 },
|
|
|
|
{ EfiRuntimeServicesCode, 0x030 },
|
|
|
|
{ EfiBootServicesCode, 0x180 },
|
|
|
|
{ EfiBootServicesData, 0xF00 },
|
2009-05-27 23:10:18 +02:00
|
|
|
{ EfiMaxMemoryType, 0x000 }
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-03-22 02:55:08 +01:00
|
|
|
EFI_PEI_PPI_DESCRIPTOR mPpiBootMode[] = {
|
|
|
|
{
|
|
|
|
EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST,
|
|
|
|
&gEfiPeiMasterBootModePpiGuid,
|
|
|
|
NULL
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2015-06-09 17:28:09 +02:00
|
|
|
UINT16 mHostBridgeDevId;
|
|
|
|
|
2014-03-04 09:01:40 +01:00
|
|
|
EFI_BOOT_MODE mBootMode = BOOT_WITH_FULL_CONFIGURATION;
|
|
|
|
|
2014-03-04 09:01:58 +01:00
|
|
|
BOOLEAN mS3Supported = FALSE;
|
|
|
|
|
2016-11-24 15:18:44 +01:00
|
|
|
UINT32 mMaxCpuCount;
|
2014-03-04 09:01:40 +01:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
VOID
|
|
|
|
AddIoMemoryBaseSizeHob (
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
UINT64 MemorySize
|
|
|
|
)
|
|
|
|
{
|
2010-07-16 21:04:41 +02:00
|
|
|
BuildResourceDescriptorHob (
|
|
|
|
EFI_RESOURCE_MEMORY_MAPPED_IO,
|
2009-05-27 23:10:18 +02:00
|
|
|
EFI_RESOURCE_ATTRIBUTE_PRESENT |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
|
2010-07-16 21:04:41 +02:00
|
|
|
EFI_RESOURCE_ATTRIBUTE_TESTED,
|
2009-05-27 23:10:18 +02:00
|
|
|
MemoryBase,
|
|
|
|
MemorySize
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
)
|
|
|
|
{
|
|
|
|
BuildResourceDescriptorHob (
|
|
|
|
EFI_RESOURCE_MEMORY_RESERVED,
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_PRESENT |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
|
2015-11-30 19:41:29 +01:00
|
|
|
(Cacheable ?
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE :
|
|
|
|
0
|
|
|
|
) |
|
2011-08-05 17:43:05 +02:00
|
|
|
EFI_RESOURCE_ATTRIBUTE_TESTED,
|
|
|
|
MemoryBase,
|
|
|
|
MemorySize
|
|
|
|
);
|
|
|
|
}
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
VOID
|
|
|
|
AddIoMemoryRangeHob (
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryLimit
|
|
|
|
)
|
|
|
|
{
|
|
|
|
AddIoMemoryBaseSizeHob (MemoryBase, (UINT64)(MemoryLimit - MemoryBase));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
AddMemoryBaseSizeHob (
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
UINT64 MemorySize
|
|
|
|
)
|
|
|
|
{
|
2010-07-16 21:04:41 +02:00
|
|
|
BuildResourceDescriptorHob (
|
|
|
|
EFI_RESOURCE_SYSTEM_MEMORY,
|
2009-05-27 23:10:18 +02:00
|
|
|
EFI_RESOURCE_ATTRIBUTE_PRESENT |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
|
2010-07-16 21:04:41 +02:00
|
|
|
EFI_RESOURCE_ATTRIBUTE_TESTED,
|
2009-05-27 23:10:18 +02:00
|
|
|
MemoryBase,
|
|
|
|
MemorySize
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
AddMemoryRangeHob (
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryBase,
|
|
|
|
EFI_PHYSICAL_ADDRESS MemoryLimit
|
|
|
|
)
|
|
|
|
{
|
|
|
|
AddMemoryBaseSizeHob (MemoryBase, (UINT64)(MemoryLimit - MemoryBase));
|
|
|
|
}
|
|
|
|
|
2011-01-21 17:51:00 +01:00
|
|
|
|
2013-12-08 02:36:15 +01:00
|
|
|
VOID
|
2014-02-01 22:22:43 +01:00
|
|
|
MemMapInitialization (
|
2013-12-08 02:36:15 +01:00
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
2016-10-21 11:59:36 +02:00
|
|
|
UINT64 PciIoBase;
|
|
|
|
UINT64 PciIoSize;
|
|
|
|
RETURN_STATUS PcdStatus;
|
2016-05-09 22:39:44 +02:00
|
|
|
|
|
|
|
PciIoBase = 0xC000;
|
|
|
|
PciIoSize = 0x4000;
|
|
|
|
|
2013-12-08 02:36:15 +01:00
|
|
|
//
|
|
|
|
// Create Memory Type Information HOB
|
|
|
|
//
|
|
|
|
BuildGuidDataHob (
|
|
|
|
&gEfiMemoryTypeInformationGuid,
|
|
|
|
mDefaultMemoryTypeInformation,
|
|
|
|
sizeof(mDefaultMemoryTypeInformation)
|
|
|
|
);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Video memory + Legacy BIOS region
|
|
|
|
//
|
|
|
|
AddIoMemoryRangeHob (0x0A0000, BASE_1MB);
|
|
|
|
|
2014-02-01 22:22:43 +01:00
|
|
|
if (!mXen) {
|
|
|
|
UINT32 TopOfLowRam;
|
2016-03-03 20:46:22 +01:00
|
|
|
UINT64 PciExBarBase;
|
2015-09-02 20:45:44 +02:00
|
|
|
UINT32 PciBase;
|
2016-02-26 16:29:19 +01:00
|
|
|
UINT32 PciSize;
|
2015-09-02 20:45:44 +02:00
|
|
|
|
2014-02-01 22:22:43 +01:00
|
|
|
TopOfLowRam = GetSystemMemorySizeBelow4gb ();
|
2016-03-19 00:08:47 +01:00
|
|
|
PciExBarBase = 0;
|
2015-09-02 20:45:44 +02:00
|
|
|
if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
|
|
|
|
//
|
2016-03-03 20:46:22 +01:00
|
|
|
// The MMCONFIG area is expected to fall between the top of low RAM and
|
|
|
|
// the base of the 32-bit PCI host aperture.
|
2015-09-02 20:45:44 +02:00
|
|
|
//
|
2016-03-03 20:46:22 +01:00
|
|
|
PciExBarBase = FixedPcdGet64 (PcdPciExpressBaseAddress);
|
|
|
|
ASSERT (TopOfLowRam <= PciExBarBase);
|
|
|
|
ASSERT (PciExBarBase <= MAX_UINT32 - SIZE_256MB);
|
|
|
|
PciBase = (UINT32)(PciExBarBase + SIZE_256MB);
|
2015-09-02 20:45:44 +02:00
|
|
|
} else {
|
|
|
|
PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
|
|
|
|
}
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2014-02-01 22:22:43 +01:00
|
|
|
//
|
|
|
|
// address purpose size
|
|
|
|
// ------------ -------- -------------------------
|
|
|
|
// max(top, 2g) PCI MMIO 0xFC000000 - max(top, 2g)
|
|
|
|
// 0xFC000000 gap 44 MB
|
|
|
|
// 0xFEC00000 IO-APIC 4 KB
|
|
|
|
// 0xFEC01000 gap 1020 KB
|
|
|
|
// 0xFED00000 HPET 1 KB
|
2015-06-09 17:28:15 +02:00
|
|
|
// 0xFED00400 gap 111 KB
|
|
|
|
// 0xFED1C000 gap (PIIX4) / RCRB (ICH9) 16 KB
|
|
|
|
// 0xFED20000 gap 896 KB
|
2014-02-01 22:22:43 +01:00
|
|
|
// 0xFEE00000 LAPIC 1 MB
|
|
|
|
//
|
2016-02-26 16:29:19 +01:00
|
|
|
PciSize = 0xFC000000 - PciBase;
|
|
|
|
AddIoMemoryBaseSizeHob (PciBase, PciSize);
|
2016-10-21 11:59:36 +02:00
|
|
|
PcdStatus = PcdSet64S (PcdPciMmio32Base, PciBase);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
|
|
|
PcdStatus = PcdSet64S (PcdPciMmio32Size, PciSize);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
|
|
|
|
2014-02-01 22:22:43 +01:00
|
|
|
AddIoMemoryBaseSizeHob (0xFEC00000, SIZE_4KB);
|
|
|
|
AddIoMemoryBaseSizeHob (0xFED00000, SIZE_1KB);
|
2015-06-09 17:28:15 +02:00
|
|
|
if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
|
|
|
|
AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
|
2016-03-03 20:46:22 +01:00
|
|
|
//
|
|
|
|
// Note: there should be an
|
|
|
|
//
|
|
|
|
// AddIoMemoryBaseSizeHob (PciExBarBase, SIZE_256MB);
|
|
|
|
//
|
|
|
|
// call below, just like the one above for RCBA. However, Linux insists
|
|
|
|
// that the MMCONFIG area be marked in the E820 or UEFI memory map as
|
|
|
|
// "reserved memory" -- Linux does not content itself with a simple gap
|
|
|
|
// in the memory map wherever the MCFG ACPI table points to.
|
|
|
|
//
|
|
|
|
// This appears to be a safety measure. The PCI Firmware Specification
|
|
|
|
// (rev 3.1) says in 4.1.2. "MCFG Table Description": "The resources can
|
|
|
|
// *optionally* be returned in [...] EFIGetMemoryMap as reserved memory
|
|
|
|
// [...]". (Emphasis added here.)
|
|
|
|
//
|
|
|
|
// Normally we add memory resource descriptor HOBs in
|
|
|
|
// QemuInitializeRam(), and pre-allocate from those with memory
|
|
|
|
// allocation HOBs in InitializeRamRegions(). However, the MMCONFIG area
|
|
|
|
// is most definitely not RAM; so, as an exception, cover it with
|
|
|
|
// uncacheable reserved memory right here.
|
|
|
|
//
|
|
|
|
AddReservedMemoryBaseSizeHob (PciExBarBase, SIZE_256MB, FALSE);
|
|
|
|
BuildMemoryAllocationHob (PciExBarBase, SIZE_256MB,
|
|
|
|
EfiReservedMemoryType);
|
2015-06-09 17:28:15 +02:00
|
|
|
}
|
2014-02-01 22:22:43 +01:00
|
|
|
AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
|
2016-05-09 22:54:36 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// On Q35, the IO Port space is available for PCI resource allocations from
|
|
|
|
// 0x6000 up.
|
|
|
|
//
|
|
|
|
if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
|
|
|
|
PciIoBase = 0x6000;
|
|
|
|
PciIoSize = 0xA000;
|
|
|
|
ASSERT ((ICH9_PMBASE_VALUE & 0xF000) < PciIoBase);
|
|
|
|
}
|
2014-02-01 22:22:43 +01:00
|
|
|
}
|
2016-05-09 22:39:44 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Add PCI IO Port space available for PCI resource allocations.
|
|
|
|
//
|
|
|
|
BuildResourceDescriptorHob (
|
|
|
|
EFI_RESOURCE_IO,
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_PRESENT |
|
|
|
|
EFI_RESOURCE_ATTRIBUTE_INITIALIZED,
|
|
|
|
PciIoBase,
|
|
|
|
PciIoSize
|
|
|
|
);
|
2016-10-21 11:59:36 +02:00
|
|
|
PcdStatus = PcdSet64S (PcdPciIoBase, PciIoBase);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
|
|
|
PcdStatus = PcdSet64S (PcdPciIoSize, PciIoSize);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
2009-05-27 23:10:18 +02:00
|
|
|
}
|
|
|
|
|
2015-09-15 10:35:14 +02:00
|
|
|
EFI_STATUS
|
|
|
|
GetNamedFwCfgBoolean (
|
|
|
|
IN CHAR8 *FwCfgFileName,
|
|
|
|
OUT BOOLEAN *Setting
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_STATUS Status;
|
|
|
|
FIRMWARE_CONFIG_ITEM FwCfgItem;
|
|
|
|
UINTN FwCfgSize;
|
|
|
|
UINT8 Value[3];
|
|
|
|
|
|
|
|
Status = QemuFwCfgFindFile (FwCfgFileName, &FwCfgItem, &FwCfgSize);
|
|
|
|
if (EFI_ERROR (Status)) {
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
if (FwCfgSize > sizeof Value) {
|
|
|
|
return EFI_BAD_BUFFER_SIZE;
|
|
|
|
}
|
|
|
|
QemuFwCfgSelectItem (FwCfgItem);
|
|
|
|
QemuFwCfgReadBytes (FwCfgSize, Value);
|
|
|
|
|
|
|
|
if ((FwCfgSize == 1) ||
|
|
|
|
(FwCfgSize == 2 && Value[1] == '\n') ||
|
|
|
|
(FwCfgSize == 3 && Value[1] == '\r' && Value[2] == '\n')) {
|
|
|
|
switch (Value[0]) {
|
|
|
|
case '0':
|
|
|
|
case 'n':
|
|
|
|
case 'N':
|
|
|
|
*Setting = FALSE;
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
|
|
|
|
case '1':
|
|
|
|
case 'y':
|
|
|
|
case 'Y':
|
|
|
|
*Setting = TRUE;
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return EFI_PROTOCOL_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define UPDATE_BOOLEAN_PCD_FROM_FW_CFG(TokenName) \
|
|
|
|
do { \
|
2016-10-21 11:59:36 +02:00
|
|
|
BOOLEAN Setting; \
|
|
|
|
RETURN_STATUS PcdStatus; \
|
2015-09-15 10:35:14 +02:00
|
|
|
\
|
|
|
|
if (!EFI_ERROR (GetNamedFwCfgBoolean ( \
|
|
|
|
"opt/ovmf/" #TokenName, &Setting))) { \
|
2016-10-21 11:59:36 +02:00
|
|
|
PcdStatus = PcdSetBoolS (TokenName, Setting); \
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus); \
|
2015-09-15 10:35:14 +02:00
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NoexecDxeInitialization (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
|
|
|
|
UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
|
|
|
|
}
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2016-03-03 20:46:22 +01:00
|
|
|
VOID
|
|
|
|
PciExBarInitialization (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
union {
|
|
|
|
UINT64 Uint64;
|
|
|
|
UINT32 Uint32[2];
|
|
|
|
} PciExBarBase;
|
|
|
|
|
|
|
|
//
|
|
|
|
// We only support the 256MB size for the MMCONFIG area:
|
|
|
|
// 256 buses * 32 devices * 8 functions * 4096 bytes config space.
|
|
|
|
//
|
|
|
|
// The masks used below enforce the Q35 requirements that the MMCONFIG area
|
|
|
|
// be (a) correctly aligned -- here at 256 MB --, (b) located under 64 GB.
|
|
|
|
//
|
|
|
|
// Note that (b) also ensures that the minimum address width we have
|
|
|
|
// determined in AddressWidthInitialization(), i.e., 36 bits, will suffice
|
|
|
|
// for DXE's page tables to cover the MMCONFIG area.
|
|
|
|
//
|
|
|
|
PciExBarBase.Uint64 = FixedPcdGet64 (PcdPciExpressBaseAddress);
|
|
|
|
ASSERT ((PciExBarBase.Uint32[1] & MCH_PCIEXBAR_HIGHMASK) == 0);
|
|
|
|
ASSERT ((PciExBarBase.Uint32[0] & MCH_PCIEXBAR_LOWMASK) == 0);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Clear the PCIEXBAREN bit first, before programming the high register.
|
|
|
|
//
|
|
|
|
PciWrite32 (DRAMC_REGISTER_Q35 (MCH_PCIEXBAR_LOW), 0);
|
|
|
|
|
|
|
|
//
|
|
|
|
// Program the high register. Then program the low register, setting the
|
|
|
|
// MMCONFIG area size and enabling decoding at once.
|
|
|
|
//
|
|
|
|
PciWrite32 (DRAMC_REGISTER_Q35 (MCH_PCIEXBAR_HIGH), PciExBarBase.Uint32[1]);
|
|
|
|
PciWrite32 (
|
|
|
|
DRAMC_REGISTER_Q35 (MCH_PCIEXBAR_LOW),
|
|
|
|
PciExBarBase.Uint32[0] | MCH_PCIEXBAR_BUS_FF | MCH_PCIEXBAR_EN
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
VOID
|
|
|
|
MiscInitialization (
|
2012-09-12 09:19:28 +02:00
|
|
|
VOID
|
2009-05-27 23:10:18 +02:00
|
|
|
)
|
|
|
|
{
|
2016-10-21 11:59:36 +02:00
|
|
|
UINTN PmCmd;
|
|
|
|
UINTN Pmba;
|
|
|
|
UINT32 PmbaAndVal;
|
|
|
|
UINT32 PmbaOrVal;
|
|
|
|
UINTN AcpiCtlReg;
|
|
|
|
UINT8 AcpiEnBit;
|
|
|
|
RETURN_STATUS PcdStatus;
|
2014-11-14 01:37:26 +01:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
//
|
|
|
|
// Disable A20 Mask
|
|
|
|
//
|
2010-10-13 09:07:29 +02:00
|
|
|
IoOr8 (0x92, BIT1);
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
//
|
2015-06-26 18:09:43 +02:00
|
|
|
// Build the CPU HOB with guest RAM size dependent address width and 16-bits
|
|
|
|
// of IO space. (Side note: unlike other HOBs, the CPU HOB is needed during
|
|
|
|
// S3 resume as well, so we build it unconditionally.)
|
2009-05-27 23:10:18 +02:00
|
|
|
//
|
2015-06-26 18:09:43 +02:00
|
|
|
BuildCpuHob (mPhysMemAddressWidth, 16);
|
2011-01-13 06:46:24 +01:00
|
|
|
|
2014-11-14 01:37:26 +01:00
|
|
|
//
|
2015-06-09 17:28:09 +02:00
|
|
|
// Determine platform type and save Host Bridge DID to PCD
|
2014-11-14 01:37:26 +01:00
|
|
|
//
|
2015-06-09 17:28:09 +02:00
|
|
|
switch (mHostBridgeDevId) {
|
2014-11-14 01:37:26 +01:00
|
|
|
case INTEL_82441_DEVICE_ID:
|
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26 20:06:07 +01:00
|
|
|
PmCmd = POWER_MGMT_REGISTER_PIIX4 (PCI_COMMAND_OFFSET);
|
2015-05-13 11:31:49 +02:00
|
|
|
Pmba = POWER_MGMT_REGISTER_PIIX4 (PIIX4_PMBA);
|
OvmfPkg: determine PMBA value dependent on host bridge device ID
In this patch, the AcpiTimerLib instances, ResetSystemLib, and PlatformPei
are modified together in order to keep VMs functional across a bisection:
they all must agree on the PMBA value used.
ResetSystemLib must not use dynamic PCDs. With SOURCE_DEBUG_ENABLE, it
gets linked into the debug agent, therefore the same restrictions apply to
it as to BaseRomAcpiTimerLib. Luckily, AcpiPmControl() is only used for
powering off the virtual machine, thus the extra cost of a PCI config
space read, compared to a PcdGet16(), should be negligible.
This is the patch that moves the PMBA to IO port 0x0600 on Q35 in
practice.
The ResetSystemLib change is easiest to verify with the "reset -s" command
in the UEFI shell (which goes through gRT->ResetSystem() and, in OVMF,
PcAtChipsetPkg/KbcResetDxe).
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
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: Gabriel Somlo <somlo@cmu.edu>
2016-05-09 21:04:47 +02:00
|
|
|
PmbaAndVal = ~(UINT32)PIIX4_PMBA_MASK;
|
|
|
|
PmbaOrVal = PIIX4_PMBA_VALUE;
|
2015-05-13 11:31:49 +02:00
|
|
|
AcpiCtlReg = POWER_MGMT_REGISTER_PIIX4 (PIIX4_PMREGMISC);
|
|
|
|
AcpiEnBit = PIIX4_PMREGMISC_PMIOSE;
|
2014-11-14 01:37:26 +01:00
|
|
|
break;
|
|
|
|
case INTEL_Q35_MCH_DEVICE_ID:
|
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26 20:06:07 +01:00
|
|
|
PmCmd = POWER_MGMT_REGISTER_Q35 (PCI_COMMAND_OFFSET);
|
2015-05-13 11:31:44 +02:00
|
|
|
Pmba = POWER_MGMT_REGISTER_Q35 (ICH9_PMBASE);
|
OvmfPkg: determine PMBA value dependent on host bridge device ID
In this patch, the AcpiTimerLib instances, ResetSystemLib, and PlatformPei
are modified together in order to keep VMs functional across a bisection:
they all must agree on the PMBA value used.
ResetSystemLib must not use dynamic PCDs. With SOURCE_DEBUG_ENABLE, it
gets linked into the debug agent, therefore the same restrictions apply to
it as to BaseRomAcpiTimerLib. Luckily, AcpiPmControl() is only used for
powering off the virtual machine, thus the extra cost of a PCI config
space read, compared to a PcdGet16(), should be negligible.
This is the patch that moves the PMBA to IO port 0x0600 on Q35 in
practice.
The ResetSystemLib change is easiest to verify with the "reset -s" command
in the UEFI shell (which goes through gRT->ResetSystem() and, in OVMF,
PcAtChipsetPkg/KbcResetDxe).
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
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: Gabriel Somlo <somlo@cmu.edu>
2016-05-09 21:04:47 +02:00
|
|
|
PmbaAndVal = ~(UINT32)ICH9_PMBASE_MASK;
|
|
|
|
PmbaOrVal = ICH9_PMBASE_VALUE;
|
2015-05-13 11:31:44 +02:00
|
|
|
AcpiCtlReg = POWER_MGMT_REGISTER_Q35 (ICH9_ACPI_CNTL);
|
|
|
|
AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
|
2014-11-14 01:37:26 +01:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
|
2015-06-09 17:28:09 +02:00
|
|
|
__FUNCTION__, mHostBridgeDevId));
|
2014-11-14 01:37:26 +01:00
|
|
|
ASSERT (FALSE);
|
|
|
|
return;
|
|
|
|
}
|
2016-10-21 11:59:36 +02:00
|
|
|
PcdStatus = PcdSet16S (PcdOvmfHostBridgePciDevId, mHostBridgeDevId);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
2014-11-14 01:37:26 +01:00
|
|
|
|
2012-09-12 09:19:28 +02:00
|
|
|
//
|
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26 20:06:07 +01:00
|
|
|
// If the appropriate IOspace enable bit is set, assume the ACPI PMBA
|
|
|
|
// has been configured (e.g., by Xen) and skip the setup here.
|
|
|
|
// This matches the logic in AcpiTimerLibConstructor ().
|
2012-09-12 09:19:28 +02:00
|
|
|
//
|
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26 20:06:07 +01:00
|
|
|
if ((PciRead8 (AcpiCtlReg) & AcpiEnBit) == 0) {
|
2011-08-05 17:43:05 +02:00
|
|
|
//
|
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26 20:06:07 +01:00
|
|
|
// The PEI phase should be exited with fully accessibe ACPI PM IO space:
|
OvmfPkg: enable PIIX4 IO space in the PEI phase
I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 09:19:16 +02:00
|
|
|
// 1. set PMBA
|
2011-08-05 17:43:05 +02:00
|
|
|
//
|
OvmfPkg: determine PMBA value dependent on host bridge device ID
In this patch, the AcpiTimerLib instances, ResetSystemLib, and PlatformPei
are modified together in order to keep VMs functional across a bisection:
they all must agree on the PMBA value used.
ResetSystemLib must not use dynamic PCDs. With SOURCE_DEBUG_ENABLE, it
gets linked into the debug agent, therefore the same restrictions apply to
it as to BaseRomAcpiTimerLib. Luckily, AcpiPmControl() is only used for
powering off the virtual machine, thus the extra cost of a PCI config
space read, compared to a PcdGet16(), should be negligible.
This is the patch that moves the PMBA to IO port 0x0600 on Q35 in
practice.
The ResetSystemLib change is easiest to verify with the "reset -s" command
in the UEFI shell (which goes through gRT->ResetSystem() and, in OVMF,
PcAtChipsetPkg/KbcResetDxe).
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
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: Gabriel Somlo <somlo@cmu.edu>
2016-05-09 21:04:47 +02:00
|
|
|
PciAndThenOr32 (Pmba, PmbaAndVal, PmbaOrVal);
|
OvmfPkg: enable PIIX4 IO space in the PEI phase
I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 09:19:16 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// 2. set PCICMD/IOSE
|
|
|
|
//
|
2014-11-14 01:37:26 +01:00
|
|
|
PciOr8 (PmCmd, EFI_PCI_COMMAND_IO_SPACE);
|
OvmfPkg: enable PIIX4 IO space in the PEI phase
I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 09:19:16 +02:00
|
|
|
|
|
|
|
//
|
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26 20:06:07 +01:00
|
|
|
// 3. set ACPI PM IO enable bit (PMREGMISC:PMIOSE or ACPI_CNTL:ACPI_EN)
|
OvmfPkg: enable PIIX4 IO space in the PEI phase
I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 09:19:16 +02:00
|
|
|
//
|
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26 20:06:07 +01:00
|
|
|
PciOr8 (AcpiCtlReg, AcpiEnBit);
|
2011-08-05 17:43:05 +02:00
|
|
|
}
|
2015-06-09 17:28:15 +02:00
|
|
|
|
|
|
|
if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
|
|
|
|
//
|
|
|
|
// Set Root Complex Register Block BAR
|
|
|
|
//
|
|
|
|
PciWrite32 (
|
|
|
|
POWER_MGMT_REGISTER_Q35 (ICH9_RCBA),
|
|
|
|
ICH9_ROOT_COMPLEX_BASE | ICH9_RCBA_EN
|
|
|
|
);
|
2016-03-03 20:46:22 +01:00
|
|
|
|
|
|
|
//
|
|
|
|
// Set PCI Express Register Range Base Address
|
|
|
|
//
|
|
|
|
PciExBarInitialization ();
|
2015-06-09 17:28:15 +02:00
|
|
|
}
|
2009-05-27 23:10:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-03-22 02:55:08 +01:00
|
|
|
VOID
|
|
|
|
BootModeInitialization (
|
2014-03-04 09:01:32 +01:00
|
|
|
VOID
|
2011-03-22 02:55:08 +01:00
|
|
|
)
|
|
|
|
{
|
2014-03-04 09:01:32 +01:00
|
|
|
EFI_STATUS Status;
|
|
|
|
|
|
|
|
if (CmosRead8 (0xF) == 0xFE) {
|
2014-03-04 09:01:40 +01:00
|
|
|
mBootMode = BOOT_ON_S3_RESUME;
|
2014-03-04 09:01:32 +01:00
|
|
|
}
|
2015-09-02 20:45:35 +02:00
|
|
|
CmosWrite8 (0xF, 0x00);
|
2011-03-22 05:54:18 +01:00
|
|
|
|
2014-03-04 09:01:40 +01:00
|
|
|
Status = PeiServicesSetBootMode (mBootMode);
|
2011-03-22 05:54:18 +01:00
|
|
|
ASSERT_EFI_ERROR (Status);
|
|
|
|
|
|
|
|
Status = PeiServicesInstallPpi (mPpiBootMode);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
2011-03-22 02:55:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-09-07 22:18:17 +02:00
|
|
|
VOID
|
|
|
|
ReserveEmuVariableNvStore (
|
|
|
|
)
|
|
|
|
{
|
|
|
|
EFI_PHYSICAL_ADDRESS VariableStore;
|
2016-10-21 11:59:36 +02:00
|
|
|
RETURN_STATUS PcdStatus;
|
2009-09-07 22:18:17 +02:00
|
|
|
|
|
|
|
//
|
|
|
|
// Allocate storage for NV variables early on so it will be
|
|
|
|
// at a consistent address. Since VM memory is preserved
|
|
|
|
// across reboots, this allows the NV variable storage to survive
|
|
|
|
// a VM reboot.
|
|
|
|
//
|
|
|
|
VariableStore =
|
|
|
|
(EFI_PHYSICAL_ADDRESS)(UINTN)
|
2017-05-06 16:02:47 +02:00
|
|
|
AllocateRuntimePages (
|
|
|
|
EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize))
|
2009-09-26 09:15:51 +02:00
|
|
|
);
|
2009-09-07 22:18:17 +02:00
|
|
|
DEBUG ((EFI_D_INFO,
|
2017-05-06 16:02:47 +02:00
|
|
|
"Reserved variable store memory: 0x%lX; size: %dkb\n",
|
2009-09-07 22:18:17 +02:00
|
|
|
VariableStore,
|
2017-05-06 16:02:47 +02:00
|
|
|
(2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
|
2009-09-07 22:18:17 +02:00
|
|
|
));
|
2016-10-21 11:59:36 +02:00
|
|
|
PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
2009-09-07 22:18:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-01-21 17:50:31 +01:00
|
|
|
VOID
|
|
|
|
DebugDumpCmos (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
2015-07-28 20:33:23 +02:00
|
|
|
UINT32 Loop;
|
2011-01-21 17:50:31 +01:00
|
|
|
|
|
|
|
DEBUG ((EFI_D_INFO, "CMOS:\n"));
|
|
|
|
|
|
|
|
for (Loop = 0; Loop < 0x80; Loop++) {
|
|
|
|
if ((Loop % 0x10) == 0) {
|
|
|
|
DEBUG ((EFI_D_INFO, "%02x:", Loop));
|
|
|
|
}
|
|
|
|
DEBUG ((EFI_D_INFO, " %02x", CmosRead8 (Loop)));
|
|
|
|
if ((Loop % 0x10) == 0xf) {
|
|
|
|
DEBUG ((EFI_D_INFO, "\n"));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-12-01 00:36:31 +01:00
|
|
|
VOID
|
|
|
|
S3Verification (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
#if defined (MDE_CPU_X64)
|
|
|
|
if (FeaturePcdGet (PcdSmmSmramRequire) && mS3Supported) {
|
|
|
|
DEBUG ((EFI_D_ERROR,
|
|
|
|
"%a: S3Resume2Pei doesn't support X64 PEI + SMM yet.\n", __FUNCTION__));
|
|
|
|
DEBUG ((EFI_D_ERROR,
|
|
|
|
"%a: Please disable S3 on the QEMU command line (see the README),\n",
|
|
|
|
__FUNCTION__));
|
|
|
|
DEBUG ((EFI_D_ERROR,
|
|
|
|
"%a: or build OVMF with \"OvmfPkgIa32X64.dsc\".\n", __FUNCTION__));
|
|
|
|
ASSERT (FALSE);
|
|
|
|
CpuDeadLoop ();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-11-24 15:18:44 +01:00
|
|
|
/**
|
|
|
|
Fetch the number of boot CPUs from QEMU and expose it to UefiCpuPkg modules.
|
|
|
|
Set the mMaxCpuCount variable.
|
|
|
|
**/
|
|
|
|
VOID
|
|
|
|
MaxCpuCountInitialization (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
|
|
|
UINT16 ProcessorCount;
|
|
|
|
RETURN_STATUS PcdStatus;
|
|
|
|
|
|
|
|
QemuFwCfgSelectItem (QemuFwCfgItemSmpCpuCount);
|
|
|
|
ProcessorCount = QemuFwCfgRead16 ();
|
|
|
|
//
|
|
|
|
// If the fw_cfg key or fw_cfg entirely is unavailable, load mMaxCpuCount
|
|
|
|
// from the PCD default. No change to PCDs.
|
|
|
|
//
|
|
|
|
if (ProcessorCount == 0) {
|
|
|
|
mMaxCpuCount = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
//
|
|
|
|
// Otherwise, set mMaxCpuCount to the value reported by QEMU.
|
|
|
|
//
|
|
|
|
mMaxCpuCount = ProcessorCount;
|
|
|
|
//
|
|
|
|
// Additionally, tell UefiCpuPkg modules (a) the exact number of VCPUs, (b)
|
|
|
|
// to wait, in the initial AP bringup, exactly as long as it takes for all of
|
|
|
|
// the APs to report in. For this, we set the longest representable timeout
|
|
|
|
// (approx. 71 minutes).
|
|
|
|
//
|
|
|
|
PcdStatus = PcdSet32S (PcdCpuMaxLogicalProcessorNumber, ProcessorCount);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
|
|
|
PcdStatus = PcdSet32S (PcdCpuApInitTimeOutInMicroSeconds, MAX_UINT32);
|
|
|
|
ASSERT_RETURN_ERROR (PcdStatus);
|
|
|
|
DEBUG ((DEBUG_INFO, "%a: QEMU reports %d processor(s)\n", __FUNCTION__,
|
|
|
|
ProcessorCount));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
/**
|
|
|
|
Perform Platform PEI initialization.
|
|
|
|
|
|
|
|
@param FileHandle Handle of the file being invoked.
|
|
|
|
@param PeiServices Describes the list of possible PEI Services.
|
|
|
|
|
|
|
|
@return EFI_SUCCESS The PEIM initialized successfully.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
EFIAPI
|
|
|
|
InitializePlatform (
|
|
|
|
IN EFI_PEI_FILE_HANDLE FileHandle,
|
|
|
|
IN CONST EFI_PEI_SERVICES **PeiServices
|
|
|
|
)
|
|
|
|
{
|
2016-04-07 12:19:23 +02:00
|
|
|
EFI_STATUS Status;
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
DEBUG ((EFI_D_ERROR, "Platform PEIM Loaded\n"));
|
|
|
|
|
2011-01-21 17:50:31 +01:00
|
|
|
DebugDumpCmos ();
|
|
|
|
|
2014-02-01 22:22:19 +01:00
|
|
|
XenDetect ();
|
2013-12-08 02:36:00 +01:00
|
|
|
|
2014-03-04 09:01:58 +01:00
|
|
|
if (QemuFwCfgS3Enabled ()) {
|
|
|
|
DEBUG ((EFI_D_INFO, "S3 support was detected on QEMU\n"));
|
|
|
|
mS3Supported = TRUE;
|
2016-04-07 12:19:23 +02:00
|
|
|
Status = PcdSetBoolS (PcdAcpiS3Enable, TRUE);
|
|
|
|
ASSERT_EFI_ERROR (Status);
|
2014-03-04 09:01:58 +01:00
|
|
|
}
|
|
|
|
|
2015-12-01 00:36:31 +01:00
|
|
|
S3Verification ();
|
2014-01-29 22:44:16 +01:00
|
|
|
BootModeInitialization ();
|
2015-06-26 18:09:39 +02:00
|
|
|
AddressWidthInitialization ();
|
2016-11-24 15:18:44 +01:00
|
|
|
MaxCpuCountInitialization ();
|
2014-01-29 22:44:16 +01:00
|
|
|
|
2017-07-04 14:50:43 +02:00
|
|
|
//
|
|
|
|
// Query Host Bridge DID
|
|
|
|
//
|
|
|
|
mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
|
|
|
|
|
2017-07-04 12:44:05 +02:00
|
|
|
if (FeaturePcdGet (PcdSmmSmramRequire)) {
|
|
|
|
Q35TsegMbytesInitialization ();
|
|
|
|
}
|
|
|
|
|
2014-01-29 22:44:09 +01:00
|
|
|
PublishPeiMemory ();
|
|
|
|
|
2014-02-01 22:22:54 +01:00
|
|
|
InitializeRamRegions ();
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2014-02-01 22:22:12 +01:00
|
|
|
if (mXen) {
|
2013-12-08 02:36:00 +01:00
|
|
|
DEBUG ((EFI_D_INFO, "Xen was detected\n"));
|
2014-02-01 22:22:19 +01:00
|
|
|
InitializeXen ();
|
2013-12-08 02:36:00 +01:00
|
|
|
}
|
2011-08-05 17:43:05 +02:00
|
|
|
|
2014-03-04 09:02:30 +01:00
|
|
|
if (mBootMode != BOOT_ON_S3_RESUME) {
|
2017-03-12 22:01:40 +01:00
|
|
|
if (!FeaturePcdGet (PcdSmmSmramRequire)) {
|
|
|
|
ReserveEmuVariableNvStore ();
|
|
|
|
}
|
2014-03-04 09:02:30 +01:00
|
|
|
PeiFvInitialization ();
|
|
|
|
MemMapInitialization ();
|
2015-09-15 10:35:14 +02:00
|
|
|
NoexecDxeInitialization ();
|
2014-03-04 09:02:30 +01:00
|
|
|
}
|
2009-05-27 23:10:18 +02:00
|
|
|
|
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
|
|
|
AmdSevInitialize ();
|
2012-09-12 09:19:28 +02:00
|
|
|
MiscInitialization ();
|
2016-07-07 15:02:11 +02:00
|
|
|
InstallFeatureControlCallback ();
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|