public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Liming Gao" <liming.gao@intel.com>
To: devel@edk2.groups.io
Cc: Mike Turner <miketur@microsoft.com>,
	Jian J Wang <jian.j.wang@intel.com>,
	Hao A Wu <hao.a.wu@intel.com>, Dandan Bi <dandan.bi@intel.com>
Subject: [Patch] MdeModulePkg DxeCore: Fix for missing MAT update
Date: Sat, 10 Aug 2019 22:10:22 +0800	[thread overview]
Message-ID: <20190810141022.18228-1-liming.gao@intel.com> (raw)

From: Mike Turner <miketur@microsoft.com>

The Fpdt driver (FirmwarePerformanceDxe) saves a memory address across
reboots, and then does an AllocatePage for that memory address.
If, on this boot, that memory comes from a Runtime memory bucket,
the MAT table is not updated. This causes Windows to boot into Recovery.

This patch blocks the memory manager from changing the page
from a special bucket to a different memory type.  Once the buckets are
allocated, we freeze the memory ranges for the OS, and fragmenting
the special buckets will cause errors resuming from hibernate.

This patch is cherry pick from Project Mu:
https://github.com/microsoft/mu_basecore/commit/a9be767d9be96af94016ebd391ea6f340920735a
With the minor change,
1. Update commit message format to keep the message in 80 characters one line.
2. Remove // MU_CHANGE comments in source code.

Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
 MdeModulePkg/Core/Dxe/Mem/Page.c | 43 ++++++++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index bd9e116aa5..637518889d 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1265,12 +1265,13 @@ CoreInternalAllocatePages (
   IN BOOLEAN                NeedGuard
   )
 {
-  EFI_STATUS      Status;
-  UINT64          Start;
-  UINT64          NumberOfBytes;
-  UINT64          End;
-  UINT64          MaxAddress;
-  UINTN           Alignment;
+  EFI_STATUS       Status;
+  UINT64           Start;
+  UINT64           NumberOfBytes;
+  UINT64           End;
+  UINT64           MaxAddress;
+  UINTN            Alignment;
+  EFI_MEMORY_TYPE  CheckType;
 
   if ((UINT32)Type >= MaxAllocateType) {
     return EFI_INVALID_PARAMETER;
@@ -1321,6 +1322,7 @@ CoreInternalAllocatePages (
   // if (Start + NumberOfBytes) rolls over 0 or
   // if Start is above MAX_ALLOC_ADDRESS or
   // if End is above MAX_ALLOC_ADDRESS,
+  // if Start..End overlaps any tracked MemoryTypeStatistics range
   // return EFI_NOT_FOUND.
   //
   if (Type == AllocateAddress) {
@@ -1336,6 +1338,35 @@ CoreInternalAllocatePages (
         (End > MaxAddress)) {
       return EFI_NOT_FOUND;
     }
+
+    // Problem summary
+
+    /*
+    A driver is allowed to call AllocatePages using an AllocateAddress type.  This type of
+    AllocatePage request the exact physical address if it is not used.  The existing code
+    will allow this request even in 'special' pages.  The problem with this is that the
+    reason to have 'special' pages for OS hibernate/resume is defeated as memory is
+    fragmented.
+    */
+
+    for (CheckType = (EFI_MEMORY_TYPE) 0; CheckType < EfiMaxMemoryType; CheckType++) {
+      if (MemoryType != CheckType &&
+          mMemoryTypeStatistics[CheckType].Special &&
+          mMemoryTypeStatistics[CheckType].NumberOfPages > 0) {
+        if (Start >= mMemoryTypeStatistics[CheckType].BaseAddress &&
+            Start <= mMemoryTypeStatistics[CheckType].MaximumAddress) {
+          return EFI_NOT_FOUND;
+        }
+        if (End >= mMemoryTypeStatistics[CheckType].BaseAddress &&
+            End <= mMemoryTypeStatistics[CheckType].MaximumAddress) {
+          return EFI_NOT_FOUND;
+        }
+        if (Start < mMemoryTypeStatistics[CheckType].BaseAddress &&
+            End   > mMemoryTypeStatistics[CheckType].MaximumAddress) {
+          return EFI_NOT_FOUND;
+        }
+      }
+    }
   }
 
   if (Type == AllocateMaxAddress) {
-- 
2.13.0.windows.1


             reply	other threads:[~2019-08-10 14:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-10 14:10 Liming Gao [this message]
2019-08-12  5:10 ` [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update Wang, Jian J
2019-08-12 16:24 ` Laszlo Ersek
2019-08-12 23:22   ` Michael D Kinney
2019-08-13  9:47     ` Laszlo Ersek
2019-08-14 14:00       ` Liming Gao
2019-08-14 15:12         ` Laszlo Ersek
2019-08-14 15:55           ` Liming Gao
2019-08-16 15:18             ` Laszlo Ersek
2019-08-16 15:24               ` Liming Gao
2019-08-16 18:54                 ` Laszlo Ersek
2019-08-19  0:40                   ` Liming Gao
2019-08-21  8:46                     ` Laszlo Ersek
2019-08-21 14:14                       ` Liming Gao
2019-08-22 11:56                         ` Laszlo Ersek
2019-08-22 14:52                           ` Liming Gao
2019-08-23 12:40                             ` 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=20190810141022.18228-1-liming.gao@intel.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