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

[Laszlo Ersek <lersek@redhat.com>]

On 06/21/17 02:52, Yao, Jiewen wrote:
> As far as I know, the real platform SmmAccessPeim may depend on
> gEfiPeiMemoryDiscoveredPpiGuid, because the SmramHob is produced in
> MRC wrapper.

Thanks for the info, Jiewen!

- I don't know what "MRC wrapper" is.

  I found "QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c",
  with the comment "Framework PEIM to initialize memory on a Quark
  Memory Controller".

- I don't know what "SmramHob" is.

  I see some hits in QuarkPlatformPkg and Vlv2TbltDevicePkg. The type
  seems to be "EFI_SMRAM_HOB_DESCRIPTOR_BLOCK", in
  "IntelFrameworkPkg/Include/Guid/SmramMemoryReserve.h", with the
  comment "GUID specific data structure of HOB for reserving SMRAM
  regions".

  I think the comment is inaccurate. From the data structure itself, it
  looks like the HOB is used to expose the possible SMRAM regions to
  "other" modules, and not to reserve regions from SMRAM. Anyway, I
  guess the HOB is consumed by modules such as:

  - QuarkSocPkg/QuarkNorthCluster/Smm/Dxe/SmmAccessDxe
  - QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei

So apparently, on Quark, the PEIM that initializes physical RAM produces
the SmramHob (which is an Intel Framework concept, apparently), and
SmmAccessPei consumes the SmramHob. In order to serialize these
operations, the two PEIMs reuse / repurpose
gEfiPeiMemoryDiscoveredPpiGuid, as a PEIM dispatch barrier. The
availability of SmramHob is parallel to the availability of
gEfiPeiMemoryDiscoveredPpiGuid.

This doesn't match OVMF for two reasons:

- In OVMF / on QEMU, we don't initialize RAM (we don't have to).

- In OVMF, we have a separate SmmAccessPei implementation, which does
  not rely on such a HOB.

Rebasing the SMM platform code in OVMF to SmramHob is out of scope, in
my opinion. The current layout of drivers works fine; we just need a new
bit pattern (11 binary) in the ESMRAMC.TSEG_SZ bitfield, and OVMF should
be able to query QEMU as to what that bit pattern translates to,
size-wise. That's all.

> At same time, I also saw a solution to use library to produce
> SmmAccessPpi. In such case, there is no dependency expression, because
> one module does 2 things: 1) init memory, 2) produce SmmAccessPpi.

I agree that this is a technical possiblity, but for OVMF it is again
out of scope. One reason is separation of concepts. Another reason is
that OVMF can be built without SMM support (that's the default
actually), and for such a build the library approach would require a
Null instance of whatever new library class we would invent. Too much
churn.

Jordan, can we please go ahead with the posted approach? If you strongly
prefer dynamic PCDs (which I *slightly* dislike), I can do that --
hacking a spurious gEfiPeiMemoryDiscoveredPpiGuid dependency into
SmmAccessPei.inf, as a serialization barrier between PCD setting and PCD
consumption --, for the sake of making progress on this series.

Thanks,
Laszlo