On Wed, Apr 12, 2023, Anish Moorthy wrote: > Add documentation, memslot flags, useful helper functions, and the > actual new capability itself. > > Memory fault exits on absent mappings are particularly useful for > userfaultfd-based postcopy live migration. When many vCPUs fault on a > single userfaultfd the faults can take a while to surface to userspace > due to having to contend for uffd wait queue locks. Bypassing the uffd > entirely by returning information directly to the vCPU exit avoids this > contention and improves the fault rate. > > Suggested-by: James Houghton <jthoughton@xxxxxxxxxx> > Signed-off-by: Anish Moorthy <amoorthy@xxxxxxxxxx> > --- > Documentation/virt/kvm/api.rst | 31 ++++++++++++++++++++++++++++--- > include/linux/kvm_host.h | 7 +++++++ > include/uapi/linux/kvm.h | 2 ++ > tools/include/uapi/linux/kvm.h | 1 + > virt/kvm/kvm_main.c | 3 +++ > 5 files changed, 41 insertions(+), 3 deletions(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index f174f43c38d45..7967b9909e28b 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -1312,6 +1312,7 @@ yet and must be cleared on entry. > /* for kvm_userspace_memory_region::flags */ > #define KVM_MEM_LOG_DIRTY_PAGES (1UL << 0) > #define KVM_MEM_READONLY (1UL << 1) > + #define KVM_MEM_ABSENT_MAPPING_FAULT (1UL << 2) This name is both too specific and too vague. It's too specific because it affects more than just "absent" mappings, it will affect any page fault that can't be resolved by fast GUP, i.e. I'm objecting for all the same reasons I objected to the exit reason being name KVM_MEMFAULT_REASON_ABSENT_MAPPING. It's too vague because it doesn't describe what behavior the flag actually enables in any way. I liked the "nowait" verbiage from the RFC. "fast_only" is an ok alternative, but that's much more of a kernel-internal name. Oliver, you had concerns with using "fault" in the name, is something like KVM_MEM_NOWAIT_ON_PAGE_FAULT or KVM_MEM_NOWAIT_ON_FAULT palatable? IMO, "fault" is perfectly ok, we just need to ensure it's unlikely to be ambiguous for userspace.
