Hi,
> During the guest creation, the boot ROM memory is pre-validated by the
> AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called
> during the SEC and PEI phase to validate the detected system RAM.
[ for this and the following few patches ]
So, sev-snp and tdx have the same fundamental requirement here. Both
must track what the state of page ranges is. Both must talk to the vmm
before they can actually use pages. snp calls this "validate", tdx
"accept", but the underlying concept should be roughly comparable.
The vmm part obviously needs to be different. I can't see any good
reason why the state tracking and the state hand over from one boot
stage to the next (vmm -> sec -> pei -> dxe -> os) should be different
though. Having a common workflow makes long-term maintenance and
testing easier.
So, can you all look at each others patches and find common ground
here? It worked out well for the WorkArea, so *please* continue
that way.
This series seems to side-step most of this by validating all memory in
the pei stage, so there is nothing to hand over to dxe and os. Only the
range where the compressed code gets uncompressed to must be passed from
sec to pei. And there is the memory range registered for pre-validation
by the vmm.
Intels (long-term?) plan seems to be to do lazily validate/accept
memory, triggered by memory allocations, to reduce boot time. Which
implies the dxe memory management core needs to be aware of page state
and invoke an vmm-specific protocol to handle validation/acceptance.
Concept posted to the list earlier this week. Slides only so far, no
patches yet.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80151): https://edk2.groups.io/g/devel/message/80151
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]
-=-=-=-=-=-=-=-=-=-=-=-
