Hi,
> > Oh, wow. So you compile in PEI, then decide at runtime whenever you use it
> > or not?
> Yes.
> In OvmfPkgX64.dsc above code will not be built into the image. So it follows
> the SEC->PEI->DXE flow.
> In IntelTdxX64.dsc, it if is Tdx guest, it jumps from SEC to DXE (see
> TdxStartup ()). Otherwise, it follows the SEC->PEI->DXE flow (Legacy guest,
> SEV guest, etc).
> > No. Please don't. That's just silly. If you don't want use PEI, ok,
> > fine, but
> > please go the way then, remove PEI from the build and take the PEI-less code
> > path in all cases.
> In the first version TDVF, we do remove the PEI from the image. The
> image only contains the SEC and DXE, and only the components TDVF
> needs. It's a slim image. Then the *ONE BINARY* requirement is
> proposed. It requires to bring up Legacy guest and Tdx guest with the
> same image. So PEI must be included in the build,
Why? Booting non-tdx guests without PEI shouldn't be fundamentally
different from a TDX guest. Memory detection needs fw_cfg instead of
the td_hob, and you have to skip some tdx setup steps, but that should
be it. Code for all that exists in PlatformPei, it only needs to be
moved to a place where SEC can use it too.
Yes, you can't include a number of features which depend on PEI into the
build then. But config-b wants be a stripped down build anyway, right?
One major advantage of having a single binary is that most aspects of
the SEC->DXE boot workflow can also be tested without TDX. Easier for
developers. Easier for CI coverage. Especially now where we talk about
pre-production hardware support.
When builing a frankenstein image which uses SEC->DXE with TDX and
SEC->PEI->DXE without TDX you loose that advantage, because that is
effectively a two-in-one binary.
> and it probes Tdx
> guest in run-time so that it decides to go to the legacy flow
> (SEC->PEI->DXE) or Tdx flow (SEC->DXE).
Ok, so the state with wave-2 merged will be:
* We have the ovmf build, which supports native/sev/tdx guests,
with basic tdx support (aka config-a).
* We have the amdsev variant (supports native/sev/not-sure-about-tdx),
which is largely identical to the normal build, only unwanted
drivers removed (no network etc), grub boot loader added and its own
PlatformBootManagerLib to have a more strict boot policy (all dxe
phase changes).
So, where to go from here?
I still think the best way forward would be to model the inteltdx build
(aka config-b) similar to the amdsev variant. Just disable the stuff
you don't need, add support for the advanced tdx features (measurement
etc), but otherwise continue to use the same SEC->PEI->DXE boot
workflow.
Advantages:
* It should be relatively easy to unify amdsev + inteltdx into one
binary.
* No quirks needed due to SEC/PEI differences. SEC can't set PCDs,
leading to patches like #9 of this series (and there was another
similar one ...).
The other route (as preferred by Jiewen) would be to not use PEI in
inteltdx. Requires some reorganization of the qemu platform
initialization code (probably move to lib) so we can run the same code
(without using cut+paste programming) in both sec and pei phase.
Clearly not my preference, but should work too.
A better solution for the PCD issue (and possibly other simliar issues
poping up later) would be good. Can't we handle that early in
PlatformDxe? So we have one single place for those quirks, and the dxe
drivers don't need to know about the SEC->DXE and SEC->PEI->DXE
differences?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84994): https://edk2.groups.io/g/devel/message/84994
Mute This Topic: https://groups.io/mt/87720802/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
