From: "Laszlo Ersek" <lersek@redhat.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>
Cc: "Ard Biesheuvel" <ard.biesheuvel@arm.com>,
"Jiewen Yao" <jiewen.yao@intel.com>,
"Jordan Justen" <jordan.l.justen@intel.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [PATCH 2/4] OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic
Date: Fri, 8 May 2020 14:16:49 +0200 [thread overview]
Message-ID: <20200508121651.16045-3-lersek@redhat.com> (raw)
In-Reply-To: <20200508121651.16045-1-lersek@redhat.com>
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>
---
OvmfPkg/PlatformPei/MemTypeInfo.c | 161 ++++++++++++++------
1 file changed, 114 insertions(+), 47 deletions(-)
diff --git a/OvmfPkg/PlatformPei/MemTypeInfo.c b/OvmfPkg/PlatformPei/MemTypeInfo.c
index 8100a2db7d44..d287fb9d7df0 100644
--- a/OvmfPkg/PlatformPei/MemTypeInfo.c
+++ b/OvmfPkg/PlatformPei/MemTypeInfo.c
@@ -1,7 +1,5 @@
/** @file
- Produce a default memory type information HOB unless we can determine, from
- the existence of the "MemoryTypeInformation" variable, that the DXE IPL PEIM
- will produce the HOB.
+ Produce the memory type information HOB.
Copyright (C) 2017-2020, Red Hat, Inc.
@@ -25,7 +23,7 @@
// of BIN hints that made sense at a particular time, for some (now likely
// unknown) workloads / boot paths.
//
-STATIC EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
+STATIC EFI_MEMORY_TYPE_INFORMATION mMemoryTypeInformation[] = {
{ EfiACPIMemoryNVS, 0x004 },
{ EfiACPIReclaimMemory, 0x008 },
{ EfiReservedMemoryType, 0x004 },
@@ -42,11 +40,117 @@ BuildMemTypeInfoHob (
{
BuildGuidDataHob (
&gEfiMemoryTypeInformationGuid,
- mDefaultMemoryTypeInformation,
- sizeof mDefaultMemoryTypeInformation
+ mMemoryTypeInformation,
+ sizeof mMemoryTypeInformation
);
- DEBUG ((DEBUG_INFO, "%a: default memory type information HOB built\n",
- __FUNCTION__));
+}
+
+/**
+ Refresh the mMemoryTypeInformation array (which we'll turn into the
+ MemoryTypeInformation HOB) from the MemoryTypeInformation UEFI variable.
+
+ Normally, the DXE IPL PEIM builds the HOB from the UEFI variable. But it does
+ so *transparently*. Instead, we consider the UEFI variable as a list of
+ hints, for updating our HOB defaults:
+
+ - Record types not covered in mMemoryTypeInformation are ignored. In
+ particular, this hides record types from the UEFI variable that may lead to
+ reboots without benefiting SMM security, such as EfiBootServicesData.
+
+ - Records that would lower the defaults in mMemoryTypeInformation are also
+ ignored.
+
+ @param[in] ReadOnlyVariable2 The EFI_PEI_READ_ONLY_VARIABLE2_PPI used for
+ retrieving the MemoryTypeInformation UEFI
+ variable.
+**/
+STATIC
+VOID
+RefreshMemTypeInfo (
+ IN EFI_PEI_READ_ONLY_VARIABLE2_PPI *ReadOnlyVariable2
+ )
+{
+ UINTN DataSize;
+ EFI_MEMORY_TYPE_INFORMATION Entries[EfiMaxMemoryType + 1];
+ EFI_STATUS Status;
+ UINTN NumEntries;
+ UINTN HobRecordIdx;
+
+ //
+ // Read the MemoryTypeInformation UEFI variable from the
+ // gEfiMemoryTypeInformationGuid namespace.
+ //
+ DataSize = sizeof Entries;
+ Status = ReadOnlyVariable2->GetVariable (
+ ReadOnlyVariable2,
+ EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
+ &gEfiMemoryTypeInformationGuid,
+ NULL,
+ &DataSize,
+ Entries
+ );
+ if (EFI_ERROR (Status)) {
+ //
+ // If the UEFI variable does not exist (EFI_NOT_FOUND), we can't use it for
+ // udpating mMemoryTypeInformation.
+ //
+ // If the UEFI variable exists but Entries is too small to hold it
+ // (EFI_BUFFER_TOO_SMALL), then the variable contents are arguably invalid.
+ // That's because Entries has room for every distinct EFI_MEMORY_TYPE,
+ // including the terminator record with EfiMaxMemoryType. Thus, we can't
+ // use the UEFI variable for updating mMemoryTypeInformation.
+ //
+ // If the UEFI variable couldn't be read for some other reason, we
+ // similarly can't use it for udpating mMemoryTypeInformation.
+ //
+ DEBUG ((DEBUG_ERROR, "%a: GetVariable(): %r\n", __FUNCTION__, Status));
+ return;
+ }
+
+ //
+ // Sanity-check the UEFI variable size against the record size.
+ //
+ if (DataSize % sizeof Entries[0] != 0) {
+ DEBUG ((DEBUG_ERROR, "%a: invalid UEFI variable size %Lu\n", __FUNCTION__,
+ (UINT64)DataSize));
+ return;
+ }
+ NumEntries = DataSize / sizeof Entries[0];
+
+ //
+ // For each record in mMemoryTypeInformation, except the terminator record,
+ // look up the first match (if any) in the UEFI variable, based on the memory
+ // type.
+ //
+ for (HobRecordIdx = 0;
+ HobRecordIdx < ARRAY_SIZE (mMemoryTypeInformation) - 1;
+ HobRecordIdx++) {
+ EFI_MEMORY_TYPE_INFORMATION *HobRecord;
+ UINTN Idx;
+ EFI_MEMORY_TYPE_INFORMATION *VariableRecord;
+
+ HobRecord = &mMemoryTypeInformation[HobRecordIdx];
+
+ for (Idx = 0; Idx < NumEntries; Idx++) {
+ VariableRecord = &Entries[Idx];
+
+ if (VariableRecord->Type == HobRecord->Type) {
+ break;
+ }
+ }
+
+ //
+ // If there is a match, allow the UEFI variable to increase NumberOfPages.
+ //
+ if (Idx < NumEntries &&
+ HobRecord->NumberOfPages < VariableRecord->NumberOfPages) {
+ DEBUG ((DEBUG_VERBOSE, "%a: Type 0x%x: NumberOfPages 0x%x -> 0x%x\n",
+ __FUNCTION__, HobRecord->Type, HobRecord->NumberOfPages,
+ VariableRecord->NumberOfPages));
+
+ HobRecord->NumberOfPages = VariableRecord->NumberOfPages;
+ }
+ }
}
/**
@@ -70,47 +174,10 @@ OnReadOnlyVariable2Available (
IN VOID *Ppi
)
{
- EFI_PEI_READ_ONLY_VARIABLE2_PPI *ReadOnlyVariable2;
- UINTN DataSize;
- EFI_STATUS Status;
-
DEBUG ((DEBUG_VERBOSE, "%a\n", __FUNCTION__));
- //
- // Check if the "MemoryTypeInformation" variable exists, in the
- // gEfiMemoryTypeInformationGuid namespace.
- //
- ReadOnlyVariable2 = Ppi;
- DataSize = 0;
- Status = ReadOnlyVariable2->GetVariable (
- ReadOnlyVariable2,
- EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME,
- &gEfiMemoryTypeInformationGuid,
- NULL,
- &DataSize,
- NULL
- );
- switch (Status) {
- case EFI_BUFFER_TOO_SMALL:
- //
- // The variable exists; the DXE IPL PEIM will build the HOB from it.
- //
- break;
- case EFI_NOT_FOUND:
- //
- // The variable does not exist; install the default memory type information
- // HOB.
- //
- BuildMemTypeInfoHob ();
- break;
- default:
- DEBUG ((DEBUG_ERROR, "%a: unexpected: GetVariable(): %r\n", __FUNCTION__,
- Status));
- ASSERT (FALSE);
- CpuDeadLoop ();
- break;
- }
-
+ RefreshMemTypeInfo (Ppi);
+ BuildMemTypeInfoHob ();
return EFI_SUCCESS;
}
--
2.19.1.3.g30247aa5d201
next prev parent reply other threads:[~2020-05-08 12:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 12:16 [PATCH 0/4] OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic Laszlo Ersek
2020-05-08 12:16 ` [PATCH 1/4] OvmfPkg/PlatformPei: don't track BS Code/Data in default MemTypeInfo HOB Laszlo Ersek
2020-05-15 17:55 ` Philippe Mathieu-Daudé
2020-05-08 12:16 ` Laszlo Ersek [this message]
2020-05-08 12:16 ` [PATCH 3/4] OvmfPkg/PlatformPei: extract memory type info defaults to PCDs Laszlo Ersek
2020-05-15 17:40 ` Philippe Mathieu-Daudé
2020-05-08 12:16 ` [PATCH 4/4] OvmfPkg/PlatformPei: increase memory type info defaults Laszlo Ersek
2020-05-12 15:19 ` [edk2-devel] [PATCH 0/4] OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic Laszlo Ersek
2020-05-15 10:10 ` Laszlo Ersek
2020-05-15 17:19 ` Ard Biesheuvel
2020-05-18 16:09 ` [edk2-devel] " Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200508121651.16045-3-lersek@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox