Re: [PATCH 1/5] OvmfPkg: introduce Q35TsegSizeLib (class header and sole lib instance)

[Jordan Justen <jordan.l.justen@intel.com>]

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 whether
> >> 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 point
> >> 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