From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.31, mailfrom: liming.gao@intel.com) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by groups.io with SMTP; Tue, 20 Aug 2019 04:57:18 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Aug 2019 04:57:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,408,1559545200"; d="scan'208";a="169060071" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga007.jf.intel.com with ESMTP; 20 Aug 2019 04:57:17 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 20 Aug 2019 04:57:17 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 20 Aug 2019 04:57:16 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.112]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.250]) with mapi id 14.03.0439.000; Tue, 20 Aug 2019 19:57:14 +0800 From: "Liming Gao" To: "Wu, Hao A" , "devel@edk2.groups.io" CC: Mike Turner , "Wang, Jian J" , "Bi, Dandan" , Laszlo Ersek Subject: Re: [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) update Thread-Topic: [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for missing Memory Attributes Table (MAT) update Thread-Index: AQHVVEjdMcD2LeyiwEaS8VQNW2vnbacB+OcggAH7SWA= Date: Tue, 20 Aug 2019 11:57:13 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D7DAE@SHSMSX104.ccr.corp.intel.com> References: <20190816153935.11192-1-liming.gao@intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWRlNDYyOTEtNWNiYS00N2FhLWExNjctNzg5MGMxZGQ4NDNmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiajZDS1pPVk53M1BqaEcra3lxSkVHbnR1RXlMcTluMUd1aHBNanpYWVh3OE1iUGM2NkNnblp0cEZCXC9SQ2VIclcifQ== dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Push @ ada905ab5c0e7ea7017e71d52219aaec1abd8dcb > -----Original Message----- > From: Wu, Hao A > Sent: Monday, August 19, 2019 1:42 PM > To: Gao, Liming ; devel@edk2.groups.io > Cc: Mike Turner ; Wang, Jian J ; Bi, Dandan ; Laszlo Ersek > > Subject: RE: [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for = missing Memory Attributes Table (MAT) update >=20 > > -----Original Message----- > > From: Gao, Liming > > Sent: Friday, August 16, 2019 11:40 PM > > To: devel@edk2.groups.io > > Cc: Mike Turner; Wang, Jian J; Wu, Hao A; Bi, Dandan; Laszlo Ersek > > Subject: [patch v2][edk2-stable201908] MdeModulePkg DxeCore: Fix for > > missing Memory Attributes Table (MAT) update > > > > 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 memor= y > > map reflects the pre-allocated bins, but the actual allocations at fixe= d > > 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/a9be767d9be96af9401 > > 6ebd391ea6f340920735a > > With the minor change, > > 1. Update commit message format to keep the message in 80 characters on= e > > 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 >=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 AllocateAddr= ess type. > > This type of > > + // AllocatePage request the exact physical address if it is not us= ed. The > > existing code > > + // will allow this request even in 'special' pages. The problem w= ith this is > > that the > > + // reason to have 'special' pages for OS hibernate/resume is defea= ted 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 >=20 > Acked-by: Hao A Wu >=20 > Best Regards, > Hao Wu >=20 >=20 > > } > > > > if (Type =3D=3D AllocateMaxAddress) { > > -- > > 2.13.0.windows.1