From nobody Mon Apr 29 01:34:52 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) client-ip=66.175.222.12; envelope-from=bounce+27952+45825+1787277+3901457@groups.io; helo=web01.groups.io; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+45825+1787277+3901457@groups.io; dmarc=fail(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1565970035; cv=none; d=zoho.com; s=zohoarc; b=TQ8m8mxLblL3meVDVwVWGGWEaR6In2JWs5SbEXDUhq9f8n95lp/QmdwEf65+7u0GHofO9WQQSaMkbbPgR0YtV+XC+pSs7nE3K1wT3p02zmR4wdGd2LJOPLxLaq0fZ1e/omMlHbmQ9OliyJcOzXbxstAOaZE1e5eCxTa2Re9KYMw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1565970035; h=Cc:Date:From:List-Id:List-Unsubscribe:Message-ID:Reply-To:Sender:Subject:To:ARC-Authentication-Results; bh=RXqEjYgs2HojwHDzQTk+pyTbvuBlDfqG92dCdScgdSE=; b=OJuTdc1ADcHWfPdq5RrRH3sSXymgpC0CDsq7YXwNAImA46D6sjmLpOI//PV4aV+LAZsAAU0GxzTzorAnRVT6b9q6BmhcPDbC6zZ1NscAHTV9dU+VW7Y6BxEbJI+esAoYDziOMBLI3+U1YhNgrWIU/sZewMm6YAB63hk7EhCXPdA= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+45825+1787277+3901457@groups.io; dmarc=fail header.from= (p=none dis=none) header.from= Received: from web01.groups.io (web01.groups.io [66.175.222.12]) by mx.zohomail.com with SMTPS id 1565970027142830.8598076807597; Fri, 16 Aug 2019 08:40:27 -0700 (PDT) Return-Path: X-Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by groups.io with SMTP; Fri, 16 Aug 2019 08:40:21 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2019 08:39:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,393,1559545200"; d="scan'208";a="377452141" X-Received: from lgao4-mobl1.ccr.corp.intel.com ([10.249.172.188]) by fmsmga006.fm.intel.com with ESMTP; 16 Aug 2019 08:39:56 -0700 From: "Liming Gao" To: devel@edk2.groups.io Cc: Mike Turner , Jian J Wang , Hao A Wu , Dandan Bi , Laszlo Ersek Subject: [edk2-devel] [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) update Date: Fri, 16 Aug 2019 23:39:35 +0800 Message-Id: <20190816153935.11192-1-liming.gao@intel.com> Precedence: Bulk List-Unsubscribe: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,liming.gao@intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=groups.io; q=dns/txt; s=20140610; t=1565970021; bh=Lsg//4wELWqCGj4KSbR238f+5bt+abQGSnLs6rWdcrc=; h=Cc:Date:From:Reply-To:Subject:To; b=EjYumNz9nn0RITd5eELKooEyKpxMmUoTq5oqFQ4DxQufEXTRs9on8X9TiX/UZm7iA3i LQ2uPhYhbG8JJjt0hbbBXIXWB/J7cmt3ToeVGcalv8GfoBjROMomnkz8c14xik99G5zHI jj+xoqUdJFDpvv9nFptCqKgHHfceOgjofzQ= X-ZohoMail-DKIM: pass (identity @groups.io) Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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/a9be767d9be96af94016ebd391e= a6f340920735a With the minor change, 1. Update commit message format to keep the message in 80 characters one li= ne. 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 Acked-by: Hao A Wu Acked-by: Laszlo Ersek Reviewed-by: Dandan Bi --- In v2, add more description for this issue.=20 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/P= age.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; =20 if ((UINT32)Type >=3D 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 =3D=3D 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 =3D (EFI_MEMORY_TYPE) 0; CheckType < EfiMaxMemoryType; = CheckType++) { + if (MemoryType !=3D CheckType && + mMemoryTypeStatistics[CheckType].Special && + mMemoryTypeStatistics[CheckType].NumberOfPages > 0) { + if (Start >=3D mMemoryTypeStatistics[CheckType].BaseAddress && + Start <=3D mMemoryTypeStatistics[CheckType].MaximumAddress) { + return EFI_NOT_FOUND; + } + if (End >=3D mMemoryTypeStatistics[CheckType].BaseAddress && + End <=3D mMemoryTypeStatistics[CheckType].MaximumAddress) { + return EFI_NOT_FOUND; + } + if (Start < mMemoryTypeStatistics[CheckType].BaseAddress && + End > mMemoryTypeStatistics[CheckType].MaximumAddress) { + return EFI_NOT_FOUND; + } + } + } } =20 if (Type =3D=3D AllocateMaxAddress) { --=20 2.13.0.windows.1 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45825): https://edk2.groups.io/g/devel/message/45825 Mute This Topic: https://groups.io/mt/32899946/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-