summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/PlatformPei/MemTypeInfo.c
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-101-5/+5
| | | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg/PlatformPei: MemTypeInfo: stop using mPlatformInfoHobGerd Hoffmann2022-12-141-2/+2
| | | | | | | | | Stop using the mPlatformInfoHob global variable in MemTypeInfoInitialization() function. Pass a pointer to the PlatformInfoHob instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: Move global variables to PlatformInfoHobMin Xu2022-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 The intention of PlatformInitLib is to extract the common function used in OvmfPkg/PlatformPei. This lib will be used not only in PEI phase but also in SEC phase. SEC phase cannot use global variables between different functions. So PlatformInfoHob is created to hold the informations shared between functions. For example, HostBridgeDevId corespond to mHostBridgeDevId in PlatformPei. In this patch we will first move below global variables to PlatformInfoHob. - mBootMode - mS3Supported - mPhysMemAddressWidth - mMaxCpuCount - mHostBridgeDevId - mQ35SmramAtDefaultSmbase - mQemuUc32Base - mS3AcpiReservedMemorySize - mS3AcpiReservedMemoryBase PlatformInfoHob also holds other information, for example, PciIoBase / PciIoSize. This is because in SEC phase, PcdSetxxx doesn't work. So we will restruct the functions which set PCDs into two, one for PlatformInfoLib, one for PlatformPei. So in this patch we first move global variables and PCDs to PlatformInfoHob. All the changes are in OvmfPkg/PlatformPei. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Apply uncrustify changesMichael Kubacki2021-12-071-31/+47
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
* OvmfPkg/PlatformPei: extract memory type info defaults to PCDsLaszlo Ersek2020-05-181-12/+9
| | | | | | | | | | | | | | | | | | | | Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace the open-coded memory type info defaults in the source code with the EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform builders can override these values with the "--pcd" option of "build", without source code updates. While at it, sort the memory type names alphabetically. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logicLaszlo Ersek2020-05-181-46/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous patch has no effect -- i.e., it cannot stop the tracking of BS Code/Data in MemTypeInfo -- if the virtual machine already has a MemoryTypeInformation UEFI variable. In that case, our current logic allows the DXE IPL PEIM to translate the UEFI variable to the HOB, and that translation is verbatim. If the variable already contains records for BS Code/Data, the issues listed in the previous patch persist for the virtual machine. For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This prevents the DXE IPL PEIM's variable-to-HOB translation. In PlatformPei, consume the records in the MemoryTypeInformation UEFI variable as hints: - Ignore all memory types for which we wouldn't by default install records in the HOB. This hides BS Code/Data from any existent MemoryTypeInformation variable. - For the memory types that our defaults cover, enable the records in the UEFI variable to increase (and *only* to increase) the page counts. This lets the MemoryTypeInformation UEFI variable function as designed, but it eliminates a reboot when such a new OVMF binary is deployed (a) that has higher memory consumption than tracked by the virtual machine's UEFI variable previously, *but* (b) whose defaults also reflect those higher page counts. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: don't track BS Code/Data in default MemTypeInfo HOBLaszlo Ersek2020-05-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit d42fdd6f8384 ("OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking of the usages of various UEFI memory types. Both whitepapers listed in that commit recommend that BS Code/Data type memory *not* be tracked. This recommendation was confirmed by Jiewen in the following two messages as well: [1] https://edk2.groups.io/g/devel/message/55741 http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97B579@shsmsx102.ccr.corp.intel.com [2] https://edk2.groups.io/g/devel/message/55749 http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97BDC5@shsmsx102.ccr.corp.intel.com While tracking BS Code/Data type memory has one benefit (it de-fragments the UEFI memory map), the downsides outweigh it. Spikes in BS Data type memory usage are not uncommon in particular, and they may have the following consequences: - such reboots during normal boot that look "spurious" to the end user, and have no SMM security benefit, - a large BS Data record in MemoryTypeInformation may cause issues when the DXE Core tries to prime the according bin(s), but the system's RAM size has been reduced meanwhile. Removing the BS Code/Data entries from MemoryTypeInformation leads to a bit more fragmentation in the UEFI memory map, but that should be harmless. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: explain EFI_MEMORY_TYPE_INFORMATION page countsLaszlo Ersek2020-03-131-0/+6
| | | | | | | | | | | | | | | | | | | | Add a code comment that explains the nature of the NumberOfPages field values. Including this kind of historical information was suggested by Leif in <https://edk2.groups.io/g/devel/message/55797> (alternative link: <http://mid.mail-archive.com/20200312104006.GB23627@bivouac.eciton.net>). Right now, the most recent commit updating the page counts has been commit 991d95636264 ("[...] Update default memory type information to reduce EFI Memory Map fragmentation.", 2010-07-16). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Suggested-by: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200312223555.29267-2-lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformationLaszlo Ersek2020-03-121-0/+147
* In the Intel whitepaper: --v-- A Tour Beyond BIOS -- Secure SMM Communication https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf --^-- bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call for action", recommend enabling the (adaptive) Memory Type Information feature. * In the Intel whitepaper: --v-- A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf --^-- figure#6 describes the Memory Type Information feature in detail; namely as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE Core, and BDS. Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling the Secure SMM Communication recommendation. In the longer term, OVMF should install the WSMT ACPI table, and this patch contributes to that. Notes: - the step in figure#6 where the UEFI variable is copied into the HOB is covered by the DXE IPL PEIM, in the DxeLoadCore() function, - "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC default TRUE value, because both whitepapers indicate that BDS needs to reset the system if the Memory Type Information changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-6-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 05:13:01 +0000