On 20.10.20 14:18, David Hildenbrand wrote: > On 20.10.20 08:18, Kirill A. Shutemov wrote: >> If the protected memory feature enabled, unmap guest memory from >> kernel's direct mappings. > > Gah, ugly. I guess this also defeats compaction, swapping, ... oh gosh. > As if all of the encrypted VM implementations didn't bring us enough > ugliness already (SEV extensions also don't support reboots, but can at > least kexec() IIRC). > > Something similar is done with secretmem [1]. And people don't seem to > like fragmenting the direct mapping (including me). > > [1] https://lkml.kernel.org/r/20200924132904.1391-1-rppt@xxxxxxxxxx > I just thought "hey, we might have to replace pud/pmd mappings by page tables when calling kernel_map_pages", this can fail with -ENOMEM, why isn't there proper error handling. Then I dived into __kernel_map_pages() which states: "The return value is ignored as the calls cannot fail. Large pages for identity mappings are not used at boot time and hence no memory allocations during large page split." I am probably missing something important, but how is calling kernel_map_pages() safe *after* booting?! I know we use it for debug_pagealloc(), but using it in a production-ready feature feels completely irresponsible. What am I missing? -- Thanks, David / dhildenb
