From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 C459921BADAAE for ; Sat, 1 Jul 2017 22:48:45 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2017 22:50:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,295,1496127600"; d="scan'208";a="1146950816" Received: from mkgovind-mobl.amr.corp.intel.com (HELO localhost) ([10.254.184.105]) by orsmga001.jf.intel.com with ESMTP; 01 Jul 2017 22:50:20 -0700 MIME-Version: 1.0 To: Laszlo Ersek Message-ID: <149897462014.32360.5464042979298034796@jljusten-skl> From: Jordan Justen In-Reply-To: <670b335c-665b-1672-6f34-d0a9d1de5e3c@redhat.com> Cc: Michael Kinney , edk2-devel-01 , Jiewen Yao , Jeff Fan References: <20170608171333.17937-1-lersek@redhat.com> <20170608171333.17937-2-lersek@redhat.com> <149789342556.32751.17592475673245441129@jljusten-skl> <384c7b21-dc46-25ba-c90e-75ae07ab5921@redhat.com> <149849999779.24605.15084992650352143991@jljusten-skl> <04147371-25a3-12d2-0cbd-6e07c816a880@redhat.com> <149851656823.26353.11207512663550762369@jljusten-skl> <149876364614.17954.18085820933912290198@jljusten-skl.jf.intel.com> <670b335c-665b-1672-6f34-d0a9d1de5e3c@redhat.com> User-Agent: alot/0.5.1 Date: Sat, 01 Jul 2017 22:50:20 -0700 Subject: Re: [PATCH 1/5] OvmfPkg: introduce Q35TsegSizeLib (class header and sole lib instance) 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: Sun, 02 Jul 2017 05:48:46 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-07-01 13:42:06, Laszlo Ersek wrote: > On 06/29/17 21:14, Jordan Justen wrote: > > On 2017-06-26 16:04:41, Laszlo Ersek wrote: > >> On 06/27/17 00:36, Jordan Justen wrote: > >>> > >>> Why can't SmramInternal.c read the size from the PCD directly? > >> > >> If I remember correctly, I wanted to base SmramAccessGetCapabilities() > >> directly on hardware configuration. At that point (regardless of wheth= er > >> the function would be called via PEI_SMM_ACCESS_PPI or > >> EFI_SMM_ACCESS2_PROTOCOL), the ESMRAMC.TSEG_SZ bits used as source for > >> the calculation would already be locked, by the SmmAccessPei entry poi= nt > >> function. > > = > > I guess it does look slightly more appropriate to read to reg, even if > > the end result will always match the PCD. The 'internal' file is used > > by PEI as well, so if you want to add a function or variable in the > > 'internal' give the mask, it sounds good. > = > I would like to introduce a global variable in SmramInternal.c, to be > set by both the PEIM's and the DXE driver's entry point functions to the > dynamic PCD value (i.e., at module startup). Sounds good. Maybe they can both call a function in SmramInternal.c to init it. Or, have a function in SmramInternal.c return the mask. -Jordan > - This global variable would be consulted in > SmramAccessGetCapabilities() (in SmramInternal.c, called from both the > corresponding PPI and protocol member functions) if, and only if, the > value read from ESMRAMC.TSEG_SZ were 11 binary. > = > - If the bit pattern read from this bit-field register were different, > then constant values would be used (exactly like now). > = > - And the dynamic PCD would never be consulted in > SmramAccessGetCapabilities(). > = > OK? > = > Thanks, > Laszlo