admin-guide/mm/userfaultfd.rst

8 Userfaults allow the implementation of on-demand paging from userland
38 Vmas are not suitable for page- (or hugepage) granular fault tracking
48 is a corner case that would currently return ``-EBUSY``).
54 ----------------------
63 - Any user can always create a userfaultfd which traps userspace page faults
67 - In order to also trap kernel page faults for the address space, either the
84 --------------------------
101 - The ``UFFD_FEATURE_EVENT_*`` flags indicate that various other events
103   detail below in the `Non-cooperative userfaultfd`_ section.
105 - ``UFFD_FEATURE_MISSING_HUGETLBFS`` and ``UFFD_FEATURE_MISSING_SHMEM``
111 - ``UFFD_FEATURE_MINOR_HUGETLBFS`` indicates that the kernel supports
116 - ``UFFD_FEATURE_MOVE`` indicates that the kernel supports moving an
138 user-faulted page.
141 --------------------
145 - ``UFFDIO_COPY`` atomically copies some existing page contents from
148 - ``UFFDIO_ZEROPAGE`` atomically zeros the new page.
150 - ``UFFDIO_CONTINUE`` maps an existing, previously-populated page.
153 see a half-populated page, since readers will keep userfaulting until the
163 - For ``UFFDIO_REGISTER_MODE_MISSING`` faults, the fault needs to be
169 - For ``UFFDIO_REGISTER_MODE_MINOR`` faults, there is an existing page (in
177 - You can tell which kind of fault occurred by examining
181 - None of the page-delivering ioctls default to the range that you
185 - You get the address of the access that triggered the missing page
191 - Be sure to test for all errors including
196 ---------------------------
209 ``msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP`` set. Now you send
225 Userfaultfd write-protect mode currently behave differently on none ptes
229 (e.g. when pages are missing and not populated).  For file-backed memories
233 as long as the page range was write-protected before.  Such a message will
237 memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ.  On
246 write-protected (so future writes will also result in a WP fault). These ioctls
251 any vma registered with write-protection will work in async mode rather
255 happens, meanwhile the write-protection will be resolved automatically by
256 the kernel.  It can be seen as a more accurate version of soft-dirty
259   - The dirty result will not be affected by vma changes (e.g. vma
262   - It supports range operations by default, so one can enable tracking on
265   - Dirty information will not get lost if the pte was zapped due to
268   - Due to a reverted meaning of soft-dirty (page clean when uffd-wp bit
269     set; dirty when uffd-wp bit cleared), it has different semantics on
272     dirtying of memory by dropping uffd-wp bit during the procedure.
275 uffd-wp bit for the pages being interested in /proc/pagemap.
277 The page will not be under track of uffd-wp async mode until the page is
278 explicitly write-protected by ``ioctl(UFFDIO_WRITEPROTECT)`` with the mode
280 that was tracked by async mode userfaultfd-wp is invalid.
282 When userfaultfd-wp async mode is used alone, it can be applied to all
286 ---------------------------
295 the VM to another physical machine. Since we want the migration to be
304 migration. Postcopy live migration is one form of memory
309 migration to QEMU.
317 It is generally beneficial to run one pass of precopy live migration
318 just before starting postcopy live migration, in order to avoid
321 The implementation of postcopy live migration currently uses one
327 in the destination node, into the socket, and the migration thread of
335 the ``userfaultfd`` and receives the fault address (or ``-EAGAIN`` in case the
337 by the parallel QEMU migration thread).
345 migration thread in the QEMU running in the destination node will
352 doesn't need to keep any per-page state bitmap relative to the live
353 migration around and a single per-page bitmap has to be maintained in
356 checked to find which missing pages to send in round robin and we seek
360 postcopy thread just before ``UFFDIO_COPY|ZEROPAGE`` runs in the migration
363 Non-cooperative userfaultfd
382 	non-cooperative process moves a virtual memory area to a
414 asynchronously and the non-cooperative process resumes execution as
418 return ``-ENOSPC`` when the monitored process exits at the time of
419 ``UFFDIO_COPY``, and ``-ENOENT``, when the non-cooperative process has changed
424 single threaded non-cooperative ``userfaultfd`` manager implementations. A