From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Fri, 16 Aug 2019 12:47:39 -0700 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 15D75309BF15; Fri, 16 Aug 2019 19:47:39 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-63.ams2.redhat.com [10.36.116.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8435419C6A; Fri, 16 Aug 2019 19:47:37 +0000 (UTC) Subject: Re: [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) update To: Liming Gao , devel@edk2.groups.io Cc: Mike Turner , Jian J Wang , Hao A Wu , Dandan Bi References: <20190816153935.11192-1-liming.gao@intel.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 16 Aug 2019 21:47:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190816153935.11192-1-liming.gao@intel.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Fri, 16 Aug 2019 19:47:39 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/16/19 17:39, Liming Gao wrote: > From: Mike Turner > > 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 (S4). > > The references to S4 here are the use case that fails. This > failure is root caused to an inconsistent behavior of the > core memory services themselves when type AllocateAddress is used. > > The main issue is apparently with the UEFI memory map -- the UEFI memory > map reflects the pre-allocated bins, but the actual allocations at fixed > addresses may go out of sync with that. Everything else, such as: > - EFI_MEMORY_ATTRIBUTES_TABLE (page protections) being out of sync, > - S4 failing > are just symptoms / consequences. > > 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. > 3. Update comments style to follow edk2 style. > > Cc: Jian J Wang > Cc: Hao A Wu > Cc: Dandan Bi > Cc: Laszlo Ersek > Signed-off-by: Liming Gao > --- > In v2, add more description for this issue. > > MdeModulePkg/Core/Dxe/Mem/Page.c | 41 ++++++++++++++++++++++++++++++++++------ > 1 file changed, 35 insertions(+), 6 deletions(-) > > diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c > index bd9e116aa5..1f0e3d94b9 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,33 @@ CoreInternalAllocatePages ( > (End > MaxAddress)) { > return EFI_NOT_FOUND; > } > + > + // > + // 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) { > Acked-by: Laszlo Ersek Please wait for maintainer approval too. Thanks Laszlo