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.20; helo=mga02.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 B251121F3884B for ; Tue, 17 Oct 2017 18:08:14 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2017 18:11:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,393,1503385200"; d="scan'208";a="1206958951" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga001.fm.intel.com with ESMTP; 17 Oct 2017 18:11:50 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Oct 2017 18:11:49 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.152]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.93]) with mapi id 14.03.0319.002; Wed, 18 Oct 2017 09:11:48 +0800 From: "Ni, Ruiyu" To: Laszlo Ersek , "edk2-devel@lists.01.org" Thread-Topic: [edk2] [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to avoid hang Thread-Index: AQHTRunVuhFydLAiv0mA0W2UVnmF3qLnJuCAgAGl2FA= Date: Wed, 18 Oct 2017 01:11:47 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BA9BE04@SHSMSX104.ccr.corp.intel.com> References: <20171017014654.274700-1-ruiyu.ni@intel.com> <4cc25dc6-89dc-a0cf-6430-61bc088b9fd9@redhat.com> In-Reply-To: <4cc25dc6-89dc-a0cf-6430-61bc088b9fd9@redhat.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsWorker to avoid hang 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, 18 Oct 2017 01:08:14 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo, I think the function name confused you. MtrrLibApplyVariableMtrrs() is not to apply the MTRR setting to CPU/HW. It's to apply the setting read from CPU/HW to the range array stored in mem= ory. It doesn't have side effect. The basic idea of MtrrDebugPrintAllMtrrsWorker() is to read the setting fro= m HW/CPU, Convert that setting to range array. Then dump the range array. -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Lasz= lo Ersek Sent: Tuesday, October 17, 2017 3:56 PM To: Ni, Ruiyu ; edk2-devel@lists.01.org Subject: Re: [edk2] [PATCH] UefiCpuPkg/MtrrLib: Fix MtrrDebugPrintAllMtrrsW= orker to avoid hang On 10/17/17 03:46, Ruiyu Ni wrote: > ARRAY_SIZE(Mtrrs->Variables.Mtrr) was used in > MtrrDebugPrintAllMtrrsWorker() to parse the MTRR registers. > Instead, the actual variable MTRR count should be used. > Otherwise, the uninitialized random data in MtrrSetting may cause > MtrrLibSetMemoryType() hang. >=20 > Steven Shi found this bug in QEMU when using Q35 chip. >=20 > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Steven Shi > Cc: Laszlo Ersek > --- > UefiCpuPkg/Library/MtrrLib/MtrrLib.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) >=20 > diff --git a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c=20 > b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c > index 2fd1d0153e..cb22558103 100644 > --- a/UefiCpuPkg/Library/MtrrLib/MtrrLib.c > +++ b/UefiCpuPkg/Library/MtrrLib/MtrrLib.c > @@ -2776,6 +2776,7 @@ MtrrDebugPrintAllMtrrsWorker ( > UINTN RangeCount; > UINT64 MtrrValidBitsMask; > UINT64 MtrrValidAddressMask; > + UINT32 VariableMtrrCount; > MTRR_MEMORY_RANGE Ranges[ > ARRAY_SIZE (mMtrrLibFixedMtrrTable) * sizeof (UINT64) + 2 * ARRAY_= SIZE (Mtrrs->Variables.Mtrr) + 1 > ]; > @@ -2785,6 +2786,8 @@ MtrrDebugPrintAllMtrrsWorker ( > return; > } > =20 > + VariableMtrrCount =3D GetVariableMtrrCountWorker (); > + > if (MtrrSetting !=3D NULL) { > Mtrrs =3D MtrrSetting; > } else { > @@ -2802,7 +2805,7 @@ MtrrDebugPrintAllMtrrsWorker ( > DEBUG((DEBUG_CACHE, "Fixed MTRR[%02d] : %016lx\n", Index, Mtrrs-= >Fixed.Mtrr[Index])); > } > =20 > - for (Index =3D 0; Index < ARRAY_SIZE (Mtrrs->Variables.Mtrr); Index+= +) { > + for (Index =3D 0; Index < VariableMtrrCount; Index++) { > if (((MSR_IA32_MTRR_PHYSMASK_REGISTER *)&Mtrrs->Variables.Mtrr[Ind= ex].Mask)->Bits.V =3D=3D 0) { > // > // If mask is not valid, then do not display range @@=20 > -2829,11 +2832,11 @@ MtrrDebugPrintAllMtrrsWorker ( > RangeCount =3D 1; > =20 > MtrrLibGetRawVariableRanges ( > - &Mtrrs->Variables, ARRAY_SIZE (Mtrrs->Variables.Mtrr), > + &Mtrrs->Variables, VariableMtrrCount, > MtrrValidBitsMask, MtrrValidAddressMask, RawVariableRanges > ); > MtrrLibApplyVariableMtrrs ( > - RawVariableRanges, ARRAY_SIZE (RawVariableRanges), > + RawVariableRanges, VariableMtrrCount, > Ranges, ARRAY_SIZE (Ranges), &RangeCount > ); > =20 >=20 Assuming this patch is not committed yet: Reviewed-by: Laszlo Ersek I have another (independent) comment: This function is currently named "MtrrDebugPrintAllMtrrsWorker", and its le= ading comment says "Worker function prints all MTRRs for debugging." Because of this name and the documentation, I didn't understand initially h= ow the problem could cause a hang, given that none of the printing loops wo= uld actually access anything out-of-bounds. Some of the information printed= would be garbage, but it should not cause a hang. That's when I noticed that the function actually *applies* MTRR settings, b= y calling MtrrLibApplyVariableMtrrs(). Even worse, the MtrrLibApplyVariableMtrrs() and MtrrLibApplyFixedMtrrs() function calls are= wrapped by DEBUG_CODE(). This means that in a DEBUG/NOOPT build, the funct= ion will apply MTRR settings, and in a RELEASE build, it won't. I think this is wrong and should be fixed. A debug function (esp. one that = behaves differently in DEBUG/NOOPT vs. RELEASE) should have no side effects= . The current situation is similar to: ASSERT (FunctionWithSideEffects () =3D=3D EXPECTED_RETURN_VALUE); which we all know is wrong. Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel