Lines Matching +full:non +full:- +full:live

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
135 user-faulted page.
138 --------------------
142 - ``UFFDIO_COPY`` atomically copies some existing page contents from
145 - ``UFFDIO_ZEROPAGE`` atomically zeros the new page.
147 - ``UFFDIO_CONTINUE`` maps an existing, previously-populated page.
150 see a half-populated page, since readers will keep userfaulting until the
160 - For ``UFFDIO_REGISTER_MODE_MISSING`` faults, the fault needs to be
166 - For ``UFFDIO_REGISTER_MODE_MINOR`` faults, there is an existing page (in
174 - You can tell which kind of fault occurred by examining
178 - None of the page-delivering ioctls default to the range that you
182 - You get the address of the access that triggered the missing page
188 - Be sure to test for all errors including
193 ---------------------------
222 Userfaultfd write-protect mode currently behave differently on none ptes
226 (e.g. when pages are missing and not populated).  For file-backed memories
230 as long as the page range was write-protected before.  Such a message will
234 memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ.  On
243 write-protected (so future writes will also result in a WP fault). These ioctls
248 ---------------------------
256 machine which experiences a real hardware memory error. Later, we live migrate
265 QEMU/KVM is using the ``userfaultfd`` syscall to implement postcopy live
266 migration. Postcopy live migration is one form of memory
270 KVM kernel code had to be modified in order to add postcopy live
279 It is generally beneficial to run one pass of precopy live migration
280 just before starting postcopy live migration, in order to avoid
283 The implementation of postcopy live migration currently uses one
297 the ``userfaultfd`` and receives the fault address (or ``-EAGAIN`` in case the
314 doesn't need to keep any per-page state bitmap relative to the live
315 migration around and a single per-page bitmap has to be maintained in
325 Non-cooperative userfaultfd
344 	non-cooperative process moves a virtual memory area to a
376 asynchronously and the non-cooperative process resumes execution as
380 return ``-ENOSPC`` when the monitored process exits at the time of
381 ``UFFDIO_COPY``, and ``-ENOENT``, when the non-cooperative process has changed
386 single threaded non-cooperative ``userfaultfd`` manager implementations. A
389 non cooperative manager, for example to allow ``UFFDIO_COPY`` ioctls to