Hi, On Mon, Feb 01, 2021 at 05:51:09PM -0800, David Rientjes wrote: > I think quite invasive changes are needed for the guest to support lazy > validation/acceptance to core areas that lots of people on the recipient > list have strong opinions about. Some things that come to mind: > > - Annotations for pages that must be pre-validated in the x86 boot > sequence, including IST stacks The problem is two-fold: 1. How to pass the information about pre-validated memory through the whole boot process. This includes firmware, boot-loader, Kernel decompressor and the early Linux boot code. 2. How to keep track of validated memory at systems runtime. (I omit the kexec case for now) For 1. the best option I see is passing this information as part of the Linux boot protocol: - First we should require from the firmware that everything in the memmap which is not marked as E820 Usable is already validated. This includes any memory used by the firmware itself. - Then we can pass this information up the boot process by extending struct boot_params. The bootloader can pass which E820 usable memory it validated, same for the kernel decompressor. The text+data (but not bss) of the running kernel image is per definition validated by the decompressor and does not need to be added explicitly to boot_params. - Once the running kernel image took over there are multiple choices. The simplest is probably to keep a validation log, but other data structures can work too until the memmap is set up. The benefit of passing it up via boot_params is that the whole process does not necessarily rely on EFI. There are some use-cases for SNP and TDX like lightweight container runtimes with only minimal or even no firmware. > - Proliferation of these annotations throughout any kernel code that can > access memory for #VC or #VE > > - Handling lazy validation of guest memory through the core mm layer, > most likely involving a bit in struct page flags to track their status Yes, I would also prefer tracking the validation info in 'struct page', once those are set up. We can discuss different options, there is no strict need for using struct page, it just seems natural to me. > - Any need for validating memory that is not backed by struct page that > needs to be special-cased When everything that is not E820 Usable is already validated then this should be a no-brainer. Shared memory with the HV and MMIO memory is not guest private anyway, so there should be no issues. Just a page_is_ram() check in the #VC/#VE handler is needed. Regards, Joerg
