Lines Matching +full:keep +full:- +full:a +full:- +full:live
10 Userfaults allow the implementation of on-demand paging from userland
14 For example userfaults allows a proper and more optimal implementation
25 1) ``read/POLLIN`` protocol to notify a userland thread of the faults
38 Vmas are not suitable for page- (or hugepage) granular fault tracking
43 passed using unix domain sockets to a manager process, so the same
44 manager process could handle the userfaults of a multitude of
48 is a corner case that would currently return ``-EBUSY``).
54 ``UFFDIO_API`` ioctl specifying a ``uffdio_api.api`` value set to ``UFFD_API`` (or
55 a later API version) which will specify the ``read/POLLIN`` protocol
82 detail below in `Non-cooperative userfaultfd`_ section.
86 register a memory range in the ``userfaultfd`` by setting the
99 memory from the ``userfaultfd`` registered range). This means a userfault
101 user-faulted page.
104 atomically copies a page into the userfault registered range and wakes
109 keep userfaulting until the copy has finished.
113 - If you requested ``UFFDIO_REGISTER_MODE_MISSING`` when registering then
116 The normal behavior of the OS automatically providing a zero page on
119 - None of the page-delivering ioctls default to the range that you
123 - You get the address of the access that triggered the missing page
124 event out of a struct uffd_msg that you read in the thread from the
126 ``UFFDIO_ZEROPAGE``. Keep in mind that unless you used DONTWAKE then
129 - Be sure to test for all errors including
134 ---------------------------
136 This is equivalent to (but faster than) using mprotect and a SIGSEGV
139 Firstly you need to register a range with ``UFFDIO_REGISTER_MODE_WP``.
156 which you supply a page and undo write protect. Note that there is a
157 difference between writes into a WP area and into a !WP area. The
160 you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
166 QEMU/KVM is using the ``userfaultfd`` syscall to implement postcopy live
167 migration. Postcopy live migration is one form of memory
168 externalization consisting of a virtual machine running with part or
169 all of its memory residing on a different node in the cloud. The
170 ``userfaultfd`` abstraction is generic enough that not a single line of
171 KVM kernel code had to be modified in order to add postcopy live
177 aren't waiting for userfaults (i.e. network bound) can keep running in
180 It is generally beneficial to run one pass of precopy live migration
181 just before starting postcopy live migration, in order to avoid
184 The implementation of postcopy live migration currently uses one
193 guest (``UFFDIO_ZEROCOPY`` is used if the source page was a zero page).
195 A different postcopy thread in the destination node listens with
196 poll() to the ``userfaultfd`` in parallel. When a ``POLLIN`` event is
197 generated after a userfault triggers, the postcopy thread read() from
198 the ``userfaultfd`` and receives the fault address (or ``-EAGAIN`` in case the
199 userfault was already resolved and waken by a ``UFFDIO_COPY|ZEROPAGE`` run
212 requested through a userfault).
215 doesn't need to keep any per-page state bitmap relative to the live
216 migration around and a single per-page bitmap has to be maintained in
226 Non-cooperative userfaultfd
245 non-cooperative process moves a virtual memory area to a
265 ``userfaultfd``, and if a page fault occurs in that area it will be
277 asynchronously and the non-cooperative process resumes execution as
281 return ``-ENOSPC`` when the monitored process exits at the time of
282 ``UFFDIO_COPY``, and ``-ENOENT``, when the non-cooperative process has changed
287 single threaded non-cooperative ``userfaultfd`` manager implementations. A
288 synchronous event delivery model can be added later as a new