On Tue, May 26, 2020 at 09:15:52AM +0300, Mike Rapoport wrote: > On Fri, May 22, 2020 at 03:52:05PM +0300, Kirill A. Shutemov wrote: > > The new VMA flag that indicate a VMA that is not accessible to userspace > > but usable by kernel with GUP if FOLL_KVM is specified. > > > > The FOLL_KVM is only used in the KVM code. The code has to know how to > > deal with such pages. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> > > --- > > include/linux/mm.h | 8 ++++++++ > > mm/gup.c | 20 ++++++++++++++++---- > > mm/huge_memory.c | 20 ++++++++++++++++---- > > mm/memory.c | 3 +++ > > mm/mmap.c | 3 +++ > > virt/kvm/async_pf.c | 4 ++-- > > virt/kvm/kvm_main.c | 9 +++++---- > > 7 files changed, 53 insertions(+), 14 deletions(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index e1882eec1752..4f7195365cc0 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -329,6 +329,8 @@ extern unsigned int kobjsize(const void *objp); > > # define VM_MAPPED_COPY VM_ARCH_1 /* T if mapped copy of data (nommu mmap) */ > > #endif > > > > +#define VM_KVM_PROTECTED 0 > > With all the ideas about removing pages from the direct mapi floating > around I wouldn't limit this to KVM. > > VM_NOT_IN_DIRECT_MAP would describe such areas better, but I realise > it's very far from perfect and nothing better does not comes to mind :) I don't like VM_NOT_IN_DIRECT_MAP. It's not only about direct mapping, but about userspace mapping as well. For the same reason other naming proposals don't fit as well. > > diff --git a/mm/mmap.c b/mm/mmap.c > > index f609e9ec4a25..d56c3f6efc99 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -112,6 +112,9 @@ pgprot_t vm_get_page_prot(unsigned long vm_flags) > > (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) | > > pgprot_val(arch_vm_get_page_prot(vm_flags))); > > > > + if (vm_flags & VM_KVM_PROTECTED) > > + ret = PAGE_NONE; > > Nit: vma_is_kvm_protected()? Which VMA? :P -- Kirill A. Shutemov
