On January 14, 2022 4:32 PM, Gerd Hoffmann wrote: > > > I don't see that PEI-less boot is required for that. Sure, when > > > stripping down the build and removing all the features which require > > > PEIMs there isn't much left to do for the PEI phase. So it makes > > > sense to look into dropping PEI altogether. But it's more a "nice to > > > have" > > > than a hard requirement, no? > > > No. I have to say PEI-less boot in Config-B is a hard requirement. > > I'm still wondering why though. I have not yet seen a reason why config-b > can't use the PEI-based boot flow. Hi, Gerd, I think Jiewen has discussed this (PEI-less boot in Config-B) in another mail thread. We can continue the discussion there. Let's first focus on the PlatformInitLib here. Thanks for your understanding. > > > > > 4. But a basic version of PlatformInitLib is a good start. > > > > > > Yes. Having initially only the functions needed by config-b in > > > PlatformInitLib is perfectly fine, but this should be a code *move* not a > copy. > > > > > > > During the development and community review, we can understand > > > > better what functions should be wrapped into PlatformInitLib. > > > > After that PlatformInitLib can be evolved for OvmfPkg/PlatformPei, > > > > Bhyve/PlatformPei, XenPlatformPei. > > > > > > Yes, most likely there are a number of opportunities to reduce code > > > duplication in the three PlatformPei variants we have by moving code > > > to the > > > (shared) PlatformInitLib. > > > > > > That can be looked at later. > > > > So let me summarize the discussion about PlatformInitLib. > > > 1. PlatformInitLib wraps the common functions in OvmfPkg/PlatformPei. > > These common functions covers the memory detection via fw_cfg, pci > > init, cmos, (MemDetect.c/Platform.c/Cmos.c). > > Yes. Everything needed for PEI-less / config-b boot moves to PlatformInitLib. > > PlatformInitLib is added as dependency to OvmfPkg/PlatformPei, so > PlatformPei can call those functions when booting with PEI. > > PEI-less boot will add PlatformInitLib to SEC (and DXE) instead so the same > code can be used then. > > Not sure how to handle cmos best. Not needed for memory detection on > qemu, but cloudhw depends on it so it is back for now. Will cloudhw support > tdx too btw? Yes, Cloudhw support TDX too. Actually we have some PoC and plan to upstream it later. BTW, cmos is needed in GetSystemMemorySizeBelow4gb which call CmosRead for 0x34/0x35. > > > And PlatformInitLib will > > not handle the S3/SMM variants. > > At least not initially. Maybe later when we move more code to the lib to > reduce code duplication in xen/bhyve/qemu PlatformPei variants. > > > 2. OvmfPkg/PlatformPei will be refactored with PlatformInitLib. The > > functions not needed by config-b stay in PlatformPei. > > > 3. Config-B support PEI-less boot for both legacy guest and td guest. > > Yes.
Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#85718): https://edk2.groups.io/g/devel/message/85718 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] -=-=-=-=-=-=-=-=-=-=-=-
