From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=jian.j.wang@intel.com; receiver=edk2-devel@lists.01.org Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E57522035522A for ; Wed, 8 Nov 2017 01:06:43 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP; 08 Nov 2017 01:10:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,363,1505804400"; d="scan'208";a="2317789" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga001.jf.intel.com with ESMTP; 08 Nov 2017 01:10:43 -0800 Received: from fmsmsx151.amr.corp.intel.com (10.18.125.4) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 8 Nov 2017 01:10:43 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX151.amr.corp.intel.com (10.18.125.4) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 8 Nov 2017 01:10:42 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.159]) with mapi id 14.03.0319.002; Wed, 8 Nov 2017 17:10:40 +0800 From: "Wang, Jian J" To: "Wang, Jian J" , Laszlo Ersek , "edk2-devel@lists.01.org" CC: "Yao, Jiewen" , "Dong, Eric" Thread-Topic: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map Thread-Index: AQHTV+vC/uDqHmlwpEW1n+2GtWyns6MJmfzAgACXLfA= Date: Wed, 8 Nov 2017 09:10:40 +0000 Message-ID: References: <20171103005729.7856-1-jian.j.wang@intel.com> <82c64ab0-25b3-5f7d-cf99-c0d2f87e99da@redhat.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTM1NWI2OWUtZWVkNi00N2E5LWE3M2UtOTk3MmEwZGI2MmFhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiIyblo0bjYwcWxic3Z1VjRrdGtRVnZDWEJKdEpcL3psWlVnY2V1V09kYWNNcFE5ZXVxN01Hckk0bk9RaVdvTCtwXC8ifQ== x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 09:06:44 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some updates below > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Wa= ng, > Jian J > Sent: Wednesday, November 08, 2017 8:11 AM > To: Laszlo Ersek ; edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Dong, Eric > Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of > RT_CODE in memory map >=20 > Hi Laszlo, >=20 > > -----Original Message----- > > From: Laszlo Ersek [mailto:lersek@redhat.com] > > Sent: Wednesday, November 08, 2017 1:14 AM > > To: Wang, Jian J ; edk2-devel@lists.01.org > > Cc: Yao, Jiewen ; Dong, Eric > > Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries = of > > RT_CODE in memory map > > > > sorry about the late response > > > > On 11/03/17 01:57, Jian J Wang wrote: > > >> v2 > > >> a. Fix an issue which will cause setting capability failure if size = is smaller > > >> than a page. > > > > > > More than one entry of RT_CODE memory might cause boot problem for > > some > > > old OSs. This patch will fix this issue to keep OS compatibility as m= uch > > > as possible. > > > > > > More detailed information, please refer to > > > https://bugzilla.tianocore.org/show_bug.cgi?id=3D753 > > > > > > Cc: Eric Dong > > > Cc: Jiewen Yao > > > Cc: Laszlo Ersek > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Jian J Wang > > > --- > > > UefiCpuPkg/CpuDxe/CpuPageTable.c | 18 ++++++++++++++---- > > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > > > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c > > b/UefiCpuPkg/CpuDxe/CpuPageTable.c > > > index d312eb66f8..4a7827ebc9 100644 > > > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c > > > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c > > > @@ -809,7 +809,9 @@ RefreshGcdMemoryAttributesFromPaging ( > > > PageLength =3D 0; > > > > > > for (Index =3D 0; Index < NumberOfDescriptors; Index++) { > > > - if (MemorySpaceMap[Index].GcdMemoryType =3D=3D > > EfiGcdMemoryTypeNonExistent) { > > > + if (MemorySpaceMap[Index].GcdMemoryType =3D=3D > > EfiGcdMemoryTypeNonExistent > > > + || (MemorySpaceMap[Index].BaseAddress & EFI_PAGE_MASK) !=3D = 0 > > > + || (MemorySpaceMap[Index].Length & EFI_PAGE_MASK) !=3D 0) { > > > continue; > > > } > > > > When exactly do the new conditions match? > > > > I thought the base addresses and the lengths in the GCD memory space ma= p > > are all page aligned. Is that not the case? > > > > If these conditions are just a sanity check (i.e. we never expect them > > to fire), then should we perpahs turn them into ASSERT()s? > > >=20 > I found that there's a mmio entry in memory map on OVMF which has size > less than a page. I didn't encounter this before. Maybe some recent chang= es > in other part of EDKII caused this situation. So ASSERT is not enough. >=20 I changed my original fix in v2 to not check the Address and Size. Instead, I'll use the Status of gDS->SetMemorySpaceCapabilities() to skip those memo= ry block which cannot be updated with new capabilities. This can avoid the=20 assumption that only the address and size will cause the calling failure. A= nd I found a logic hole in code. You'll find new changes in v3 patch. > > > > > > @@ -829,6 +831,15 @@ RefreshGcdMemoryAttributesFromPaging ( > > > // Sync real page attributes to GCD > > > BaseAddress =3D MemorySpaceMap[Index].BaseAddress; > > > MemorySpaceLength =3D MemorySpaceMap[Index].Length; > > > + Capabilities =3D MemorySpaceMap[Index].Capabilities | > > > + EFI_MEMORY_PAGETYPE_MASK; > > > + Status =3D gDS->SetMemorySpaceCapabilities ( > > > + BaseAddress, > > > + MemorySpaceLength, > > > + Capabilities > > > + ); > > > + ASSERT_EFI_ERROR (Status); > > > + > > > > OK, so I guess we simply add EFI_MEMORY_PAGETYPE_MASK to the > > capabilities of all memory space map entries that have a type different > > from non-existent. We discussed it before and (apparently) it is > > considered safe. > > >=20 > Yes. I've validated different OSs boot. It's safe to stay this way. >=20 > > > while (MemorySpaceLength > 0) { > > > if (PageLength =3D=3D 0) { > > > PageEntry =3D GetPageTableEntry (&PagingContext, BaseAddress= , > > &PageAttribute); > > > @@ -846,7 +857,6 @@ RefreshGcdMemoryAttributesFromPaging ( > > > if (Attributes !=3D (MemorySpaceMap[Index].Attributes & > > EFI_MEMORY_PAGETYPE_MASK)) { > > > DoUpdate =3D TRUE; > > > Attributes |=3D (MemorySpaceMap[Index].Attributes & > > ~EFI_MEMORY_PAGETYPE_MASK); > > > - Capabilities =3D Attributes | MemorySpaceMap[Index].Capabi= lities; > > > } else { > > > DoUpdate =3D FALSE; > > > } > > > @@ -854,8 +864,8 @@ RefreshGcdMemoryAttributesFromPaging ( > > > > > > Length =3D MIN (PageLength, MemorySpaceLength); > > > if (DoUpdate) { > > > - gDS->SetMemorySpaceCapabilities (BaseAddress, Length, Capabi= lities); > > > - gDS->SetMemorySpaceAttributes (BaseAddress, Length, Attribut= es); > > > + Status =3D gDS->SetMemorySpaceAttributes (BaseAddress, Lengt= h, > > Attributes); > > > + ASSERT_EFI_ERROR (Status); > > > DEBUG ((DEBUG_INFO, "Update memory space attribute: > [%02d] %016lx > > - %016lx (%08lx -> %08lx)\r\n", > > > Index, BaseAddress, BaseAddress + Lengt= h - 1, > > > MemorySpaceMap[Index].Attributes, Attri= butes)); > > > > > > > I'll let you decide about the EFI_PAGE_MASK conditions near the top. > > > > Acked-by: Laszlo Ersek > > >=20 > Thanks. >=20 > > Thanks > > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel