audk/OvmfPkg/PlatformPei/Platform.c

681 lines
19 KiB
C
Raw Normal View History

/**@file
Platform PEI driver
Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
Copyright (c) 2011, Andrei Warkentin <andreiw@motorola.com>
This program and the accompanying materials
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
//
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/HobLib.h>
#include <Library/IoLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/PcdLib.h>
#include <Library/PciLib.h>
#include <Library/PeimEntryPoint.h>
#include <Library/PeiServicesLib.h>
#include <Library/QemuFwCfgLib.h>
#include <Library/QemuFwCfgS3Lib.h>
#include <Library/ResourcePublicationLib.h>
#include <Guid/MemoryTypeInformation.h>
#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>
#include <OvmfPlatforms.h>
#include "Platform.h"
#include "Cmos.h"
EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
{ EfiACPIMemoryNVS, 0x004 },
{ EfiACPIReclaimMemory, 0x008 },
{ EfiReservedMemoryType, 0x004 },
{ EfiRuntimeServicesData, 0x024 },
{ EfiRuntimeServicesCode, 0x030 },
{ EfiBootServicesCode, 0x180 },
{ EfiBootServicesData, 0xF00 },
{ EfiMaxMemoryType, 0x000 }
};
EFI_PEI_PPI_DESCRIPTOR mPpiBootMode[] = {
{
EFI_PEI_PPI_DESCRIPTOR_PPI | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST,
&gEfiPeiMasterBootModePpiGuid,
NULL
}
};
UINT16 mHostBridgeDevId;
EFI_BOOT_MODE mBootMode = BOOT_WITH_FULL_CONFIGURATION;
BOOLEAN mS3Supported = FALSE;
UINT32 mMaxCpuCount;
VOID
AddIoMemoryBaseSizeHob (
EFI_PHYSICAL_ADDRESS MemoryBase,
UINT64 MemorySize
)
{
BuildResourceDescriptorHob (
EFI_RESOURCE_MEMORY_MAPPED_IO,
EFI_RESOURCE_ATTRIBUTE_PRESENT |
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
EFI_RESOURCE_ATTRIBUTE_TESTED,
MemoryBase,
MemorySize
);
}
VOID
AddReservedMemoryBaseSizeHob (
EFI_PHYSICAL_ADDRESS MemoryBase,
UINT64 MemorySize,
BOOLEAN Cacheable
)
{
BuildResourceDescriptorHob (
EFI_RESOURCE_MEMORY_RESERVED,
EFI_RESOURCE_ATTRIBUTE_PRESENT |
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
(Cacheable ?
EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE :
0
) |
EFI_RESOURCE_ATTRIBUTE_TESTED,
MemoryBase,
MemorySize
);
}
VOID
AddIoMemoryRangeHob (
EFI_PHYSICAL_ADDRESS MemoryBase,
EFI_PHYSICAL_ADDRESS MemoryLimit
)
{
AddIoMemoryBaseSizeHob (MemoryBase, (UINT64)(MemoryLimit - MemoryBase));
}
VOID
AddMemoryBaseSizeHob (
EFI_PHYSICAL_ADDRESS MemoryBase,
UINT64 MemorySize
)
{
BuildResourceDescriptorHob (
EFI_RESOURCE_SYSTEM_MEMORY,
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 |
EFI_RESOURCE_ATTRIBUTE_TESTED,
MemoryBase,
MemorySize
);
}
VOID
AddMemoryRangeHob (
EFI_PHYSICAL_ADDRESS MemoryBase,
EFI_PHYSICAL_ADDRESS MemoryLimit
)
{
AddMemoryBaseSizeHob (MemoryBase, (UINT64)(MemoryLimit - MemoryBase));
}
VOID
MemMapInitialization (
VOID
)
{
UINT64 PciIoBase;
UINT64 PciIoSize;
RETURN_STATUS PcdStatus;
PciIoBase = 0xC000;
PciIoSize = 0x4000;
//
// Create Memory Type Information HOB
//
BuildGuidDataHob (
&gEfiMemoryTypeInformationGuid,
mDefaultMemoryTypeInformation,
sizeof(mDefaultMemoryTypeInformation)
);
//
// Video memory + Legacy BIOS region
//
AddIoMemoryRangeHob (0x0A0000, BASE_1MB);
if (!mXen) {
UINT32 TopOfLowRam;
OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35 The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Micha Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Micha Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Micha Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 20:46:22 +01:00
UINT64 PciExBarBase;
UINT32 PciBase;
UINT32 PciSize;
TopOfLowRam = GetSystemMemorySizeBelow4gb ();
PciExBarBase = 0;
if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
//
OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35 The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Micha Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Micha Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Micha Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
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.
//
OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35 The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Micha Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Micha Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Micha Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
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);
} else {
PciBase = (TopOfLowRam < BASE_2GB) ? BASE_2GB : TopOfLowRam;
}
//
// 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
// 0xFED00400 gap 111 KB
// 0xFED1C000 gap (PIIX4) / RCRB (ICH9) 16 KB
// 0xFED20000 gap 896 KB
// 0xFEE00000 LAPIC 1 MB
//
PciSize = 0xFC000000 - PciBase;
AddIoMemoryBaseSizeHob (PciBase, PciSize);
PcdStatus = PcdSet64S (PcdPciMmio32Base, PciBase);
ASSERT_RETURN_ERROR (PcdStatus);
PcdStatus = PcdSet64S (PcdPciMmio32Size, PciSize);
ASSERT_RETURN_ERROR (PcdStatus);
AddIoMemoryBaseSizeHob (0xFEC00000, SIZE_4KB);
AddIoMemoryBaseSizeHob (0xFED00000, SIZE_1KB);
if (mHostBridgeDevId == INTEL_Q35_MCH_DEVICE_ID) {
AddIoMemoryBaseSizeHob (ICH9_ROOT_COMPLEX_BASE, SIZE_16KB);
OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35 The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Micha Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Micha Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Micha Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
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);
}
AddIoMemoryBaseSizeHob (PcdGet32(PcdCpuLocalApicBaseAddress), SIZE_1MB);
//
// 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);
}
}
//
// Add PCI IO Port space available for PCI resource allocations.
//
BuildResourceDescriptorHob (
EFI_RESOURCE_IO,
EFI_RESOURCE_ATTRIBUTE_PRESENT |
EFI_RESOURCE_ATTRIBUTE_INITIALIZED,
PciIoBase,
PciIoSize
);
PcdStatus = PcdSet64S (PcdPciIoBase, PciIoBase);
ASSERT_RETURN_ERROR (PcdStatus);
PcdStatus = PcdSet64S (PcdPciIoSize, PciIoSize);
ASSERT_RETURN_ERROR (PcdStatus);
}
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 { \
BOOLEAN Setting; \
RETURN_STATUS PcdStatus; \
\
if (!EFI_ERROR (GetNamedFwCfgBoolean ( \
"opt/ovmf/" #TokenName, &Setting))) { \
PcdStatus = PcdSetBoolS (TokenName, Setting); \
ASSERT_RETURN_ERROR (PcdStatus); \
} \
} while (0)
VOID
NoexecDxeInitialization (
VOID
)
{
UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
}
OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35 The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Micha Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Micha Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Micha Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
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
);
}
VOID
MiscInitialization (
VOID
)
{
UINTN PmCmd;
UINTN Pmba;
UINT32 PmbaAndVal;
UINT32 PmbaOrVal;
UINTN AcpiCtlReg;
UINT8 AcpiEnBit;
RETURN_STATUS PcdStatus;
//
// Disable A20 Mask
//
IoOr8 (0x92, BIT1);
//
OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width Maoming reported that guest memory sizes equal to or larger than 64GB were not correctly handled by OVMF. Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and starting QEMU with 64GB guest RAM size, I found the following error in the OVMF debug log: > GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000) > GcdMemoryType = Reserved > Capabilities = 030000000000000F > Status = Unsupported This message is emitted when the DXE core is initializing the memory space map, processing the "above 4GB" memory resource descriptor HOB that was created by OVMF's QemuInitializeRam() function (see "UpperMemorySize"). The DXE core's call chain fails in: CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c] CoreConvertSpace() // // Search for the list of descriptors that cover the range BaseAddress // to BaseAddress+Length // CoreSearchGcdMapEntry() CoreSearchGcdMapEntry() fails because the one entry (with type "nonexistent") in the initial GCD memory space map is too small, and cannot be split to cover the memory space range being added: > GCD:Initial GCD Memory Space Map > GCDMemType Range Capabilities Attributes > ========== ================================= ================ ================ > NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000 The size of this initial entry is determined from the CPU HOB (CoreInitializeGcdServices()). Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth, which is the narrowest valid value to cover the entire guest RAM. Reported-by: Maoming <maoming.maoming@huawei.com> Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Maoming <maoming.maoming@huawei.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
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.)
//
OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width Maoming reported that guest memory sizes equal to or larger than 64GB were not correctly handled by OVMF. Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and starting QEMU with 64GB guest RAM size, I found the following error in the OVMF debug log: > GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000) > GcdMemoryType = Reserved > Capabilities = 030000000000000F > Status = Unsupported This message is emitted when the DXE core is initializing the memory space map, processing the "above 4GB" memory resource descriptor HOB that was created by OVMF's QemuInitializeRam() function (see "UpperMemorySize"). The DXE core's call chain fails in: CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c] CoreConvertSpace() // // Search for the list of descriptors that cover the range BaseAddress // to BaseAddress+Length // CoreSearchGcdMapEntry() CoreSearchGcdMapEntry() fails because the one entry (with type "nonexistent") in the initial GCD memory space map is too small, and cannot be split to cover the memory space range being added: > GCD:Initial GCD Memory Space Map > GCDMemType Range Capabilities Attributes > ========== ================================= ================ ================ > NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000 The size of this initial entry is determined from the CPU HOB (CoreInitializeGcdServices()). Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth, which is the narrowest valid value to cover the entire guest RAM. Reported-by: Maoming <maoming.maoming@huawei.com> Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Maoming <maoming.maoming@huawei.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-26 18:09:43 +02:00
BuildCpuHob (mPhysMemAddressWidth, 16);
//
// Determine platform type and save Host Bridge DID to PCD
//
switch (mHostBridgeDevId) {
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);
Pmba = POWER_MGMT_REGISTER_PIIX4 (PIIX4_PMBA);
PmbaAndVal = ~(UINT32)PIIX4_PMBA_MASK;
PmbaOrVal = PIIX4_PMBA_VALUE;
AcpiCtlReg = POWER_MGMT_REGISTER_PIIX4 (PIIX4_PMREGMISC);
AcpiEnBit = PIIX4_PMREGMISC_PMIOSE;
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);
Pmba = POWER_MGMT_REGISTER_Q35 (ICH9_PMBASE);
PmbaAndVal = ~(UINT32)ICH9_PMBASE_MASK;
PmbaOrVal = ICH9_PMBASE_VALUE;
AcpiCtlReg = POWER_MGMT_REGISTER_Q35 (ICH9_ACPI_CNTL);
AcpiEnBit = ICH9_ACPI_CNTL_ACPI_EN;
break;
default:
DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
__FUNCTION__, mHostBridgeDevId));
ASSERT (FALSE);
return;
}
PcdStatus = PcdSet16S (PcdOvmfHostBridgePciDevId, mHostBridgeDevId);
ASSERT_RETURN_ERROR (PcdStatus);
//
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 ().
//
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) {
//
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
//
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
//
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);
}
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
);
OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35 The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Micha Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Micha Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Micha Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 20:46:22 +01:00
//
// Set PCI Express Register Range Base Address
//
PciExBarInitialization ();
}
}
VOID
BootModeInitialization (
OvmfPkg: PlatformPei: detect S3 Resume in CMOS and set boot mode accordingly Data is transferred between S3 Suspend and S3 Resume as follows: S3 Suspend (DXE): (1) BdsLibBootViaBootOption() EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe] - saves ACPI S3 Context to LockBox ---------------------+ (including FACS address -- FACS ACPI table | contains OS waking vector) | | - prepares boot script: | EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe] | S3BootScriptLib [PiDxeS3BootScriptLib] | - opcodes & arguments are saved in NVS. --+ | | | - issues a notification by installing | | EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL | | | | (2) EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - closes script with special opcode <---------+ | - script is available in non-volatile memory | via PcdS3BootScriptTablePrivateDataPtr --+ | | | BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - Knows about boot script location by <----+ | synchronizing with the other library | instance via | PcdS3BootScriptTablePrivateDataPtr. | - Copies relocated image of itself to | reserved memory. --------------------------------+ | - Saved image contains pointer to boot script. ---|--+ | | | | Runtime: | | | | | | (3) OS is booted, writes OS waking vector to FACS, | | | suspends machine | | | | | | S3 Resume (PEI): | | | | | | (4) PlatformPei sets S3 Boot Mode based on CMOS | | | | | | (5) DXE core is skipped and EFI_PEI_S3_RESUME2 is | | | called as last step of PEI | | | | | | (6) S3Resume2Pei retrieves from LockBox: | | | - ACPI S3 Context (path to FACS) <------------------|--|--+ | | | +------------------|--|--+ - Boot Script Executor Image <----------------------+ | | | | (7) BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - executes boot script <-----------------------------+ | | (8) OS waking vector available from ACPI S3 Context / FACS <--+ is called Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: move code into BootModeInitialization] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15290 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 09:01:32 +01:00
VOID
)
{
OvmfPkg: PlatformPei: detect S3 Resume in CMOS and set boot mode accordingly Data is transferred between S3 Suspend and S3 Resume as follows: S3 Suspend (DXE): (1) BdsLibBootViaBootOption() EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe] - saves ACPI S3 Context to LockBox ---------------------+ (including FACS address -- FACS ACPI table | contains OS waking vector) | | - prepares boot script: | EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe] | S3BootScriptLib [PiDxeS3BootScriptLib] | - opcodes & arguments are saved in NVS. --+ | | | - issues a notification by installing | | EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL | | | | (2) EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - closes script with special opcode <---------+ | - script is available in non-volatile memory | via PcdS3BootScriptTablePrivateDataPtr --+ | | | BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - Knows about boot script location by <----+ | synchronizing with the other library | instance via | PcdS3BootScriptTablePrivateDataPtr. | - Copies relocated image of itself to | reserved memory. --------------------------------+ | - Saved image contains pointer to boot script. ---|--+ | | | | Runtime: | | | | | | (3) OS is booted, writes OS waking vector to FACS, | | | suspends machine | | | | | | S3 Resume (PEI): | | | | | | (4) PlatformPei sets S3 Boot Mode based on CMOS | | | | | | (5) DXE core is skipped and EFI_PEI_S3_RESUME2 is | | | called as last step of PEI | | | | | | (6) S3Resume2Pei retrieves from LockBox: | | | - ACPI S3 Context (path to FACS) <------------------|--|--+ | | | +------------------|--|--+ - Boot Script Executor Image <----------------------+ | | | | (7) BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - executes boot script <-----------------------------+ | | (8) OS waking vector available from ACPI S3 Context / FACS <--+ is called Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: move code into BootModeInitialization] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15290 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 09:01:32 +01:00
EFI_STATUS Status;
if (CmosRead8 (0xF) == 0xFE) {
mBootMode = BOOT_ON_S3_RESUME;
OvmfPkg: PlatformPei: detect S3 Resume in CMOS and set boot mode accordingly Data is transferred between S3 Suspend and S3 Resume as follows: S3 Suspend (DXE): (1) BdsLibBootViaBootOption() EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe] - saves ACPI S3 Context to LockBox ---------------------+ (including FACS address -- FACS ACPI table | contains OS waking vector) | | - prepares boot script: | EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe] | S3BootScriptLib [PiDxeS3BootScriptLib] | - opcodes & arguments are saved in NVS. --+ | | | - issues a notification by installing | | EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL | | | | (2) EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - closes script with special opcode <---------+ | - script is available in non-volatile memory | via PcdS3BootScriptTablePrivateDataPtr --+ | | | BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - Knows about boot script location by <----+ | synchronizing with the other library | instance via | PcdS3BootScriptTablePrivateDataPtr. | - Copies relocated image of itself to | reserved memory. --------------------------------+ | - Saved image contains pointer to boot script. ---|--+ | | | | Runtime: | | | | | | (3) OS is booted, writes OS waking vector to FACS, | | | suspends machine | | | | | | S3 Resume (PEI): | | | | | | (4) PlatformPei sets S3 Boot Mode based on CMOS | | | | | | (5) DXE core is skipped and EFI_PEI_S3_RESUME2 is | | | called as last step of PEI | | | | | | (6) S3Resume2Pei retrieves from LockBox: | | | - ACPI S3 Context (path to FACS) <------------------|--|--+ | | | +------------------|--|--+ - Boot Script Executor Image <----------------------+ | | | | (7) BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - executes boot script <-----------------------------+ | | (8) OS waking vector available from ACPI S3 Context / FACS <--+ is called Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: move code into BootModeInitialization] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15290 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04 09:01:32 +01:00
}
CmosWrite8 (0xF, 0x00);
Status = PeiServicesSetBootMode (mBootMode);
ASSERT_EFI_ERROR (Status);
Status = PeiServicesInstallPpi (mPpiBootMode);
ASSERT_EFI_ERROR (Status);
}
VOID
ReserveEmuVariableNvStore (
)
{
EFI_PHYSICAL_ADDRESS VariableStore;
RETURN_STATUS PcdStatus;
//
// 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)
AllocateRuntimePages (
EFI_SIZE_TO_PAGES (2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize))
);
DEBUG ((EFI_D_INFO,
"Reserved variable store memory: 0x%lX; size: %dkb\n",
VariableStore,
(2 * PcdGet32 (PcdFlashNvStorageFtwSpareSize)) / 1024
));
PcdStatus = PcdSet64S (PcdEmuVariableNvStoreReserved, VariableStore);
ASSERT_RETURN_ERROR (PcdStatus);
}
VOID
DebugDumpCmos (
VOID
)
{
UINT32 Loop;
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"));
}
}
}
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
}
/**
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));
}
/**
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
)
{
EFI_STATUS Status;
DEBUG ((DEBUG_INFO, "Platform PEIM Loaded\n"));
DebugDumpCmos ();
XenDetect ();
if (QemuFwCfgS3Enabled ()) {
DEBUG ((EFI_D_INFO, "S3 support was detected on QEMU\n"));
mS3Supported = TRUE;
Status = PcdSetBoolS (PcdAcpiS3Enable, TRUE);
ASSERT_EFI_ERROR (Status);
}
S3Verification ();
BootModeInitialization ();
AddressWidthInitialization ();
MaxCpuCountInitialization ();
//
// Query Host Bridge DID
//
mHostBridgeDevId = PciRead16 (OVMF_HOSTBRIDGE_DID);
if (FeaturePcdGet (PcdSmmSmramRequire)) {
Q35TsegMbytesInitialization ();
}
PublishPeiMemory ();
InitializeRamRegions ();
if (mXen) {
DEBUG ((EFI_D_INFO, "Xen was detected\n"));
InitializeXen ();
}
if (mBootMode != BOOT_ON_S3_RESUME) {
if (!FeaturePcdGet (PcdSmmSmramRequire)) {
ReserveEmuVariableNvStore ();
}
PeiFvInitialization ();
MemMapInitialization ();
NoexecDxeInitialization ();
}
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 ();
MiscInitialization ();
InstallFeatureControlCallback ();
return EFI_SUCCESS;
}