Intel Preparing Linux Kernel Support For "Unaccepted Memory"
What's unaccepted memory? With the UEFI v2.9 specification update from earlier this year, it introduces the notion of unaccepted memory / memory acceptance. Principally it's focused on virtual machines and that the memory must first be "accepted" by the guest before it can be allocated and used within the guest's confines. The actual accepting handling process is dependent upon the specific VM hypervisor.
Memory acceptance for VMs was pursued to reduce the performance costs associated with over-allocating memory by postponing it until it's actually needed. Memory overhead is reduced and boot times are quicker as a result. The UEFI v2.9 specification also notes the unaccepted memory path helps protect against a class of possible attacks against the VM platform.
Intel Trust Domain Extensions (TDX) and AMD SEV-SNP support this "unaccepted memory" capability for VMs. Intel detailed TDX last year and since then has been working on the TDX support patches for the Linux kernel in advance of supported hardware being announced. TDX has yet to be found in any released Intel processor but presumably coming with Xeon Sapphire Rapids or otherwise Granite Rapids, but in either case the Linux support is already underway for on-demand unaccepted memory. (Intel's programming reference guides still just show TDX as for "future processors" without committing to Sapphire Rapids, unlike AMX, PKS, UINTR, and other features the same guides explicitly confirm for Sapphire Rapids.)
AMD EPYC 7003 "Milan" processors released earlier this year with SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) already support this feature. However, AMD engineers have yet to publish any Linux patches on the kernel mailing list for bringing up the support for the mainline kernel to just accept the memory as needed by the VM. Intel is once again leading the charge even though they don't have capable CPUs out yet with this functionality while AMD does and they are lagging behind in their upstream Linux software support.
AMD for their part is still working on upstreaming the SEV-SNP base support in the Linux kernel -- again, sad to see it taking months into post-launch time for that to settle. Since the March debut of Milan, they have at least offered their out-of-tree kernel work but are behind in their upstreaming effort once again and especially compared to Intel that continues to ensure their new hardware features are supported under Linux well in advance of launch. Thankfully AMD continues hiring more Linux engineers so we will hopefully see more punctual feature support moving forward.
The existing yet-to-be-merged SEV-SNP patches for Linux are performing pre-validation of memory -- validating the entire portion of RAM before control is handed over to the guest kernel rather than accepting (on-demand) and validating as-needed by the VM. Thus with that current approach all of the memory acceptance is being done at boot time, leading to potentially slower VM starts and any associated extra memory overhead.
Intel's patches around this on-demand unaccepted memory support are focused just on TDX but do touch common kernel code -- the core memory management code and x86 EFI code -- so should help AMD when they get to working on their SEV-SNP-based on-demand unaccepted memory (or "lazy validation" as it's also been referenced to in some of the SEV-SNP patches) support for the mainline Linux kernel.
With this unaccepted memory support patches only being published now, it's likely too late the work will be settled in time for the 5.15 kernel given there already are some suggested improvements and the new merge window being just weeks away, but otherwise could appear in v5.16 or later.
10 Comments
