search

AMDESE / ovmf

EDK2 / OVMF related projects
BSD 2-Clause "Simplified" License
6 stars 21 forks source link

RFC lazy accept changes from TDX adapted to SEV-SNP #4

Closed deeglaze closed 2 years ago

deeglaze commented 2 years ago

The Intel folks have been working on "lazy accept" in Linux and their own fork of OVMF. Brijesh Singh wrote AMDESE/linux/v12+unaccepted for the Linux side of adaptation for SEV-SNP, and a colleague Sophia Wolf and I have had a go at adapting OVMF changes to work for SEV-SNP. Each commit here references the Intel edk2-staging TDVF branch they've created for TDX changes. I have not been able to boot v12+unaccepted with these changes, but want to get y'all's sense of if this is the right approach to adaptation for SEV-SNP.

The novel commits here are 3efcfe44af65627c9869afc86956de070d137528 and c1985122bebce580593c14b76fc6627c1a8ca65e. The rest are verbatim from the TDVF branch.

tlendacky commented 2 years ago

Can this be simplified for the SNP case? The Page State Change call can take multiple pages/ranges in a single call, so there is a lot less vm-exiting doing a block accept vs. one at a time later. What would be the difference in time (from OVMF entry to grub menu) if you were to accept up to the first 4GB (2GB really because of the MMIO hole) and leave the remaining memory to be accepted by the kernel or DXE for memory allocations above 4GB?

deeglaze commented 2 years ago

Given Intel's changes will be accepted into OVMF, only 2 commits here would be new for SNP, and 1 is a trivial implementation of the MemoryAccept protocol. I think accepting all hobs <= 4GiB instead of this range mess could be acceptable for most VMs, but for enclave-like UEFI applications, they'll want to have better startup behavior that doesn't need to accept so much memory up front.