summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/PlatformPei/MemDetect.c
Commit message (Collapse)AuthorAgeFilesLines
...
* OvmfPkg/PlatformPei: silence X64 VS2015x86 warningLaszlo Ersek2016-07-181-1/+1
| | | | | | | | | | | | | | | | | | VS2015x86 reports the following warning for "OvmfPkg/PlatformPei/MemDetect.c": > MemDetect.c(357): error C2220: warning treated as error - no 'object' > file generated > MemDetect.c(357): warning C4244: '=': conversion from 'UINT64' to > 'UINT32', possible loss of data LowerMemorySize is first assigned from GetSystemMemorySizeBelow4gb(), which returns UINT32. Change the type of LowerMemorySize accordingly. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3Laszlo Ersek2016-07-151-12/+28
| | | | | | | | | | | | | | | | | | | | | Move the permanent PEI memory for the S3 resume boot path to the top of the low RAM (just below TSEG if the SMM driver stack is included in the build). The new size is derived from CpuMpPei's approximate memory demand. Save the base address and the size in new global variables, regardless of the boot path. On the normal boot path, use these variables for covering the area with EfiACPIMemoryNVS type memory. PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused in PlatformPei; remove them. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformPei: create one memory HOB at S3 resume too, for CpuMpPeiLaszlo Ersek2016-07-151-1/+23
| | | | | | | | | | | | | | | | | | | | CpuMpPei will have to place the AP startup vector in memory under 1MB. For this, CpuMpPei borrows memory under 1MB, but it needs a memory resource descriptor HOB to exist there even on the S3 resume path (see the GetWakeupBuffer() function). Produce such a HOB as an exception on the S3 resume path. CpuMpPei is going be dispatched no earlier than PlatformPei, because CpuMpPei has a depex on gEfiPeiMemoryDiscoveredPpiGuid, and PlatformPei calls PublishSystemMemory(). Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformPei: Add memory above 4GB as testedRuiyu Ni2016-05-041-2/+2
| | | | | | | | | | Since PlatformBootManagerLib do not run memory test to convert untested memory to tested. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXELaszlo Ersek2016-03-231-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main observation about the 64-bit PCI host aperture is that it is the highest part of the useful address space. It impacts the top of the GCD memory space map, and, consequently, our maximum address width calculation for the CPU HOB too. Thus, modify the GetFirstNonAddress() function to consider the following areas above the high RAM, while calculating the first non-address (i.e., the highest inclusive address, plus one): - the memory hotplug area (optional, the size comes from QEMU), - the 64-bit PCI host aperture (we set a default size). While computing the first non-address, capture the base and the size of the 64-bit PCI host aperture at once in PCDs, since they are natural parts of the calculation. (Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path (see the InitializePlatform() -> MemMapInitialization() condition), nor are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them, through our PciHostBridgeLib instance.) Set 32GB as the default size for the aperture. Issue#59 mentions the NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these cards may have 24GB of memory (probably 16GB + 8GB BARs). As a strictly experimental feature, the user can specify the size of the aperture (in MB) as well, with the QEMU option -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536 The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning that the property is experimental, unstable, and might go away any time. Gerd has proposed heuristics for sizing the aperture automatically (based on 1GB page support and PCPU address width), but such should be delayed to a later patch (which may very well back out "X-PciMmio64Mb" then). For "everyday" guests, the 32GB default for the aperture size shouldn't impact the PEI memory demand (the size of the page tables that the DXE IPL PEIM builds). Namely, we've never reported narrower than 36-bit addresses; the DXE IPL PEIM has always built page tables for 64GB at least. For the aperture to bump the address width above 36 bits, either the guest must have quite a bit of memory itself (in which case the additional PEI memory demand shouldn't matter), or the user must specify a large aperture manually with "X-PciMmio64Mb" (and then he or she is also responsible for giving enough RAM to the VM, to satisfy the PEI memory demand). Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Thomas Lamprecht <t.lamprecht@proxmox.com> Ref: https://github.com/tianocore/edk2/issues/59 Ref: http://www.nvidia.com/object/tesla-servers.html Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: PlatformPei: factor out GetFirstNonAddress()Laszlo Ersek2016-03-231-1/+17
| | | | | | | | | | | | | | | Factor out the expression that is currently the basis of the address width calculation into a standalone function. In the next patches we'll raise the return value under certain circumstances. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Thomas Lamprecht <t.lamprecht@proxmox.com> Ref: https://github.com/tianocore/edk2/issues/59 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: PlatformPei: don't allocate fake lockbox if SMM_REQUIRELaszlo Ersek2015-11-301-19/+21
| | | | | | | | | | | | | | | | Since our fake LockBox must not be selected with -D SMM_REQUIRE (see the previous patch), it makes sense to set aside memory for it only if -D SMM_REQUIRE is absent. Modify InitializeRamRegions() accordingly. This patch completes the -D SMM_REQUIRE-related tweaking of the special OVMF memory areas. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19047 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire setLaszlo Ersek2015-11-301-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations: - PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed so that it ends with the RAM below 4GB, - QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are created for the RAM below 4GB; plus MTRR attributes are set (independently of S3 vs. normal boot) - MemMapInitialization(): an MMIO resource descriptor HOB is created for PCI resource allocation, on normal boot, starting at max(RAM below 4GB, 2GB). The first two of these is adjusted for the configured TSEG size, if PcdSmmSmramRequire is set: - In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG. - In QemuInitializeRam(), we must keep the DXE out of TSEG. One idea would be to simply trim the [1MB .. LowerMemorySize] memory resource descriptor HOB, leaving a hole for TSEG in the memory space map. The SMM IPL will however want to massage the caching attributes of the SMRAM range that it loads the SMM core into, with gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So, instead of trimming this range, split the TSEG area off, and report it as a cacheable reserved memory resource. Finally, since reserved memory can be allocated too, pre-allocate TSEG in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that this step alone does not suffice without the resource descriptor HOB trickery: if we omit that, then the DXE IPL PEIM fails to load and start the DXE core.) - In MemMapInitialization(), the start of the PCI MMIO range is not affected. We choose the largest option (8MB) for the default TSEG size. Michael Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm consumes SMRAM proportionally to the number of CPUs. From the three options available, he reported that 8MB was both necessary and sufficient for the SMBASE relocation to succeed with 255 CPUs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3137 - http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3177 Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19039 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is setLaszlo Ersek2015-11-301-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is not trusted and we should defend against it tampering with the firmware's data. One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is decompressed on the first boot by SEC, then the OS preserves it across S3 suspend-resume cycles; at S3 resume SEC just reuses the originally decompressed PEIFV. However, if we don't trust the OS, then SEC must decompress PEIFV from the pristine flash every time, lest we execute OS-injected code or work with OS-injected data. Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV; the decompression brings DXEFV with itself, plus it uses a temporary output buffer and a scratch buffer too, which even reach above the end of the finally installed DXEFV. For this reason we must keep away a non-malicious OS from DXEFV too, plus the memory up to PcdOvmfDecomprScratchEnd. The delay introduced by the LZMA decompression on S3 resume is negligible. If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE (from the DEC file), and then this patch has no effect (not counting some changed debug messages). If QEMU doesn't support S3 (or the user disabled it on the QEMU command line), then this patch has no effect also. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@19037 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()Laszlo Ersek2015-06-261-4/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment we work with a UC default MTRR type, and set three memory ranges to WB: - [0, 640 KB), - [1 MB, LowerMemorySize), - [4 GB, 4 GB + UpperMemorySize). Unfortunately, coverage for the third range can fail with a high likelihood. If the alignment of the base (ie. 4 GB) and the alignment of the size (UpperMemorySize) differ, then MtrrLib creates a series of variable MTRR entries, with power-of-two sized MTRR masks. And, it's really easy to run out of variable MTRR entries, dependent on the alignment difference. This is a problem because a Linux guest will loudly reject any high memory that is not covered my MTRR. So, let's follow the inverse pattern (loosely inspired by SeaBIOS): - flip the MTRR default type to WB, - set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default type and variable MTRRs, so we can't avoid this, - set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs, - set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs more likely than the other scheme (due to less chaotic alignment differences). Effects of this patch can be observed by setting DEBUG_CACHE (0x00200000) in PcdDebugPrintErrorLevel. 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: 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@17722 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()Laszlo Ersek2015-06-261-5/+4
| | | | | | | | | | | | | | Build the memory HOBs in a tight block, in increasing base address order. 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: 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@17721 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: enable larger permanent PEI RAMLaszlo Ersek2015-06-261-3/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We'll soon increase the maximum guest-physical RAM size supported by OVMF. For more RAM, the DXE IPL is going to build more page tables, and for that it's going to need a bigger chunk from the permanent PEI RAM. Otherwise CreateIdentityMappingPageTables() would fail with: > DXE IPL Entry > Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi > Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260 > AllocatePages failed: No 0x40201 Pages is available. > There is only left 0x3F1F pages memory resource to be allocated. > ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123): > BigPageAddress != 0 (The above example belongs to the artificially high, maximal address width of 52, clamped by the DXE core to 48. The address width of 48 bits corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging structures.) Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Brian J. Johnson <bjohnson@sgi.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brian J. Johnson <bjohnson@sgi.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17719 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Fix VS2005 build warningsJordan Justen2014-09-251-1/+1
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16171 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3Laszlo Ersek2014-04-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF's SecMain is unique in the sense that it links against the following two libraries *in combination*: - IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/ LzmaCustomDecompressLib.inf - MdePkg/Library/BaseExtractGuidedSectionLib/ BaseExtractGuidedSectionLib.inf The ExtractGuidedSectionLib library class allows decompressor modules to register themselves (keyed by GUID) with it, and it allows clients to decompress file sections with a registered decompressor module that matches the section's GUID. BaseExtractGuidedSectionLib is a library instance (of type BASE) for this library class. It has no constructor function. LzmaCustomDecompressLib is a compatible decompressor module (of type BASE). Its section type GUID is gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor function is executed, which registers its LZMA decompressor with the above GUID, by calling into BaseExtractGuidedSectionLib: LzmaDecompressLibConstructor() [GuidedSectionExtraction.c] ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c] GetExtractGuidedSectionHandlerInfo() PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS Later, during a normal (non-S3) boot, SecMain utilizes this decompressor to get information about, and to decompress, sections of the OVMF firmware image: SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c] SecStartupPhase2() FindAndReportEntryPoints() FindPeiCoreImageBase() DecompressMemFvs() ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c] ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c] Notably, only the extraction depends on full-config-boot; the registration of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI binary, triggered by the library constructor function. This is where the bug happens. BaseExtractGuidedSectionLib maintains the table of GUIDed decompressors (section handlers) at a fixed memory location; selected by PcdGuidedExtractHandlerTableAddress (declared in MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB). This causes SecMain to corrupt guest OS memory during S3, leading to random crashes. Compare the following two memory dumps, the first taken right before suspending, the second taken right after resuming a RHEL-7 guest: crash> rd -8 -p 1000000 0x50 1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3.............. 1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8....... 1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo 1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so......... vs. crash> rd -8 -p 1000000 0x50 1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... ....... 1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ............... 1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{.... 1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo 1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so......... The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE declared in MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c. Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at guest-phys offset 0x1000020. Fix the problem as follows: - Carve out 4KB from the 36KB gap that we currently have between PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB and PcdOvmfSecPeiTempRamBase == 8256 KB. - Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000). - Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is supported and we're not currently resuming. The 4KB size that we pick is an upper estimate for BaseExtractGuidedSectionLib's internal storage size. The latter is calculated as follows (see GetExtractGuidedSectionHandlerInfo()): sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32 PcdMaximumGuidedExtractHandler * ( sizeof(GUID) + // 16 sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8 sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8 ) OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes. Regarding the lifecycle of the new area: (a) when and how it is initialized after first boot of the VM The library linked into SecMain finds that the area lacks the signature. It initializes the signature, plus the rest of the structure. This is independent of S3 support. Consumption of the area is also limited to SEC (but consumption does depend on full-config-boot). (b) how it is protected from memory allocations during DXE It is not, in the general case; and we don't need to. Nothing else links against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area. (c) how it is protected from the OS When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions(). When S3 is not supported, the range is not protected. (d) how it is accessed on the S3 resume path Examined by the library linked into SecMain. Registrations update the table in-place (based on GUID matches). (e) how it is accessed on the warm reset path If S3 is enabled, then the OS won't damage the table (due to (c)), hence see (d). If S3 is unsupported, then the OS may or may not overwrite the signature. (It likely will.) This is identical to the pre-patch status. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@15433 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: lifecycle fixes for the LockBox areaLaszlo Ersek2014-03-311-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If (mBootMode == BOOT_ON_S3_RESUME) -- that is, we are resuming --, then the patch has no observable effect. If (mBootMode != BOOT_ON_S3_RESUME && mS3Supported) -- that is, we are booting or rebooting, and S3 is supported), then the patch has no observable effect either. If (mBootMode != BOOT_ON_S3_RESUME && !mS3Supported) -- that is, we are booting or rebooting, and S3 is unsupported), then the patch effects the following two fixes: - The LockBox storage is reserved from DXE (but not the OS). Drivers in DXE may save data in the LockBox regardless of S3 support, potentially corrupting any overlapping allocations. Make sure there's no overlap. - The LockBox storage is cleared. A LockBox inherited across a non-resume reboot, populated with well-known GUIDs, breaks drivers that want to save entries with those GUIDs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Matt Fleming <matt.fleming@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15418 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: implement LockBoxLibLaszlo Ersek2014-03-041-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | The S3 suspend/resume infrastructure depends on the LockBox library class. The edk2 tree currently contains Null and SMM instances. The Null instance is useless, and the SMM instance would require SMM emulation by including the SMM core and adding several new drivers, which is deemed too complex. Hence add a simple LockBoxLib instance for OVMF. jordan.l.justen@intel.com: * use PCDs instead of EmuNvramLib - clear memory in PlatformPei on non S3 boots * allocate NVS memory and store a pointer to that memory - reduces memory use at fixed locations Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> 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@15301 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: reserve early page tables on X64Laszlo Ersek2014-03-041-0/+14
| | | | | | | | | | | | | | | | | On X64, the reset vector code in "OvmfPkg/ResetVector/Ia32/PageTables64.asm" identity maps the first 4GB of RAM for PEI, consuming six frames starting at 8MB. This range is declared by the PcdOvmfSecPageTablesBase/Size PCDs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [jordan.l.justen@intel.com: Move to MemDetect.c; use PCDs] 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@15298 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: reserve SEC/PEI temp RAM for S3 resumeLaszlo Ersek2014-03-041-0/+11
| | | | | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [jordan.l.justen@intel.com: move to MemDetect.c; use PCDs] 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@15297 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/PlatformPei: Skip various items for S3 resumeJordan Justen2014-03-041-6/+10
| | | | | | | | | | | | | | | | | We will not be running DXE on S3 resume, so we don't need to do these initialization items: * Reserve EMU Variable memory range * Declare Firmware volumes * Add memory HOBs v5: * Move MiscInitialization back to running on S3 resume 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@15295 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add section of memory to use for PEI on S3 resumeJordan Justen2014-03-041-10/+26
| | | | | | | | | | | | | | | | | This 32k section of RAM will be declared to the PEI Core on S3 resume to allow memory allocations during S3 resume PEI. If the boot mode is BOOT_ON_S3_RESUME, then we publish the pre-reserved PcdS3AcpiReservedMemory range to PEI. If the boot mode is not BOOT_ON_S3_RESUME, then we reserve this range as ACPI NVS so the OS will not use it. 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@15294 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/PlatformPei: Remove duplicate Xen memory map debug messageJordan Justen2014-02-091-1/+0
| | | | | | | | | | This duplicate message was intended to be removed from r15207 before it was committed. (It was pointed out by Wei Liu.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15213 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/PlatformPei: Add RAM for Xen in InitializeRamRegionsJordan Justen2014-02-011-1/+6
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15207 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/PlatformPei: Add InitializeRamRegions functionJordan Justen2014-02-011-8/+17
| | | | | | | | | | | In the next commit we will update the Xen boot path to also use this function. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15206 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/PlatformPei: Merge Xen support into MemMapInitializationJordan Justen2014-02-011-3/+3
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15205 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/PlatformPei: Call PublishPeiMemory in one placeJordan Justen2014-01-291-2/+0
| | | | | | | | | | | | The Xen and QEMU/KVM paths were calling this at nearly the same time in the boot flow anyhow, so just make the call in one spot. 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@15195 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Split MAINFV into a separate PEI and DXE FVsJordan Justen2014-01-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By splitting the PEI and DXE phases into separate FVs, we can only reserve the PEI FV for ACPI S3 support. This should save about 7MB. Unfortunately, this all has to happen in a single commit. DEC: * Remove PcdOvmfMemFv(Base|Size) * Add PcdOvmfPeiMemFv(Base|Size) * Add PcdOvmfDxeMemFv(Base|Size) FDF: * Add new PEIFV. Move PEI modules here. * Remove MAINFV * Add PEIFV and DXEFV into FVMAIN_COMPACT - They are added as 2 sections of a file, and compressed together so they should retain good compression * PcdOvmf(Pei|Dxe)MemFv(Base|Size) are set SEC: * Find both the PEI and DXE FVs after decompression. - Copy them separately to their memory locations. Platform PEI driver: * Fv.c: Publish both FVs as appropriate * MemDetect.c: PcdOvmfMemFv(Base|Size) => PcdOvmfDxeMemFv(Base|Size) OVMF.fd before: Non-volatile data storage FVMAIN_COMPACT uncompressed FV FFS file LZMA compressed MAINFV uncompressed individual PEI modules uncompressed FV FFS file compressed with PI_NONE DXEFV uncompressed individual DXE modules uncompressed SECFV uncompressed OVMF.fd after: Non-volatile data storage FVMAIN_COMPACT uncompressed FV FFS file LZMA compressed PEIFV uncompressed individual PEI modules uncompressed DXEFV uncompressed individual DXE modules uncompressed SECFV uncompressed 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@15151 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: reuse PublishPeiMemory() in MemDetect()Laszlo Ersek2013-12-261-18/+4
| | | | | | | | | | | | | Although SVN r14944 ("OvmfPkg: introduce PublishPeiMemory") copied a big chunk of code from MemDetect(), calling the new PublishPeiMemory() function in MemDetect() could not have replaced the original code in the latter. However, with the help of the previous patch, we can do it now. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@15023 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: simplify memory range expressions in MemDetect()Laszlo Ersek2013-12-261-4/+3
| | | | | | | | | | Exploit that (MemoryBase + MemorySize) always equals LowerMemorySize. 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://svn.code.sf.net/p/edk2/code/trunk/edk2@15022 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce PublishPeiMemoryWei Liu2013-12-081-1/+35
| | | | | | | | | | | | | | | | MemDetect actully does too many things, the underlying platform might want to have more control over memory layout. Extract the functionality of publishing PEI memory to a dedicated function. Also fixed wrong comment while I was there. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14944 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/PlatformPei: Remove MtrrLib ASSERTsjljusten2011-10-311-6/+3
| | | | | | | | | | QEMU doesn't support MTRR emulation in some cases, and therefore the MtrrLib calls may return an error. In that case, we should silently ignore the error. Signed-off-by: jljusten git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12618 6f19259b-4bc3-4df7-8a09-765794883524
* Set MTRR registers.vanjeff2011-10-281-1/+11
| | | | | | | | Signed-off-by: vanjeff Reviewed-by: rsun3 git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12589 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add support for memory above 4GBjljusten2011-01-211-7/+38
| | | | | | | | When QEMU has more than 3.5GB of RAM, it will map the additional memory above 4GB. This change will make that RAM accessible to OVMF. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11266 6f19259b-4bc3-4df7-8a09-765794883524
* OVMF: Support greater than 2GB of memoryjljusten2010-10-131-3/+3
| | | | git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10928 6f19259b-4bc3-4df7-8a09-765794883524
* Update the copyright notice formathhtian2010-04-281-2/+2
| | | | git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10439 6f19259b-4bc3-4df7-8a09-765794883524
* OVMF: Update OVMF FD/FV build to minimize ROM sizejljusten2010-01-041-4/+12
| | | | | | | | | * Only SEC is uncompressed now * The MAIN FV with PEI & DXE can easily shrink and grow as needed * The final output will now be OVMF.Fv rather than OVMF.fd * The final output size will be a multiple of 64kb git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9672 6f19259b-4bc3-4df7-8a09-765794883524
* Add initial version of Open Virtual Machine Firmware (OVMF) platform.jljusten2009-05-271-0/+100
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8398 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-09 17:26:41 +0000