Messages in this thread | | | Subject | Re: [RFCv2 15/16] KVM: Unmap protected pages from direct mapping | From | David Hildenbrand <> | Date | Tue, 20 Oct 2020 15:20:13 +0200 |
| |
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@kernel.org >
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
| |