Re: [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx

Gerd Hoffmann


[Jiewen] OK, I talked with Min again. 12ms is not right data today.
We have bigger number, but I cannot share the data according to legal reason.

But I agree with your statement that, if the data is small enough, then we don't need MP in sec.

I propose this way:
1) In first patch, we drop MP in SEC.
Yes. Next implement lazy accept ...

2) We can revisit if it is really needed later, when the TDX platform is about to launch.
... then revisit where we stand in terms of boot performance.

And, yes, doing that on the final tdx platform hardware instead
of preliminary development hardware makes sense too.

Where does the 50% increase for GPAW=52 comes from?
[Jiewen] Yes, this is about page table.
The reason is that UEFI spec requires you to map all memory. You have to create page table for all.
Seems that has changed with the latest (2.9) revision of the specs which
explicitly excludes unaccepted memory. From section 2.3.4:

Paging mode is enabled and any memory space defined by the UEFI
memory map is identity mapped (virtual address equals physical
address), although the attributes of certain regions may not have
all read, write, and execute attributes or be unmarked for purposes
of platform protection. The mappings to other regions, such as those
for unaccepted memory, are undefined and may vary from
implementation to implementation.

So implementing lazy accept should bring the initial memory footprint
down because page tables for unaccepted memory are not needed in
SEC/PEI. We can lazily allocate them in DXE instead when accepting
memory (either all memory, or just enough to load the linux kernel and
have linux accept the remaining memory).

take care,

Join to automatically receive all group messages.