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

[Laszlo Ersek <lersek@redhat.com>]

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).

- 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