[edk2-devel] [PATCH v6 15/29] OvmfPkg/MemEncryptSevLib: add support to validate system RAM

[Gerd Hoffmann]

  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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-