Hi,
> IIRC, in the TDX proposal, I got the impression that TDX implementation
> will skip the PEI phase, and it jumps from SEC->DXE. The SEC phase
> somehow will know the guest memory range and validate it.
Well, their design review document lists two configurations, one (named
"config-a" in the slides) following the existing boot flow and another
("config-b") which skips PEI.
The motivation for config-b is not clear from the design review
document. The slides describe what they are doing but there isn't much
information on _why_ things are done that way. Asked a few days ago,
answer is still outstanding.
I'd prefer to not have two completely different initialization code
paths in ovmf. Easier for TDX/SNP code sharing, also easier for
long-term maintenance.
> Approach #1
>
> The main advantage is that EDK2 core and guest OS can accept the memory
> without any validation step. [ ... ]
> Approach #2
>
> The main advantage of this approach is that it can support lazy
> validation, and it can undoubtedly help reduce boot time. [ ... ]
> This patch series implements #1. And we will be looking at approach #2
> after the base is enabled. Approach #2 builds upon #1. As you
> highlighted below that we have not seen the patches for the Lazy
> validation here so its hard to comment but I am hopeful that it will
> integrated just fine with the SNP.
Good, that plan makes sense to me.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80206): https://edk2.groups.io/g/devel/message/80206
Mute This Topic: https://groups.io/mt/85306676/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
