Lines Matching full:page

10 memory page faults, something otherwise only the kernel code could do.
19 regions of virtual memory with it. Then, any page faults which occur within the
38 Vmas are not suitable for page- (or hugepage) granular fault tracking
58 handle kernel page faults have been a useful tool for exploiting the kernel).
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
80 to /dev/userfaultfd can always create userfaultfds that trap kernel page faults;
99 events, except page fault notifications, may be generated:
102   other than page faults are supported. These events are described in more
117   existing page contents from userspace.
138 user-faulted page.
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
160 Which ioctl to choose depends on the kind of page fault, and what we'd
164   resolved by either providing a new page (``UFFDIO_COPY``), or mapping
165   the zero page (``UFFDIO_ZEROPAGE``). By default, the kernel would map
166   the zero page for a missing fault. With userfaultfd, userspace can
169 - For ``UFFDIO_REGISTER_MODE_MINOR`` faults, there is an existing page (in
170   the page cache). Userspace has the option of modifying the page's
172   (modified or not), userspace asks the kernel to map the page and let the
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
218 which you supply a page and undo write protect.  Note that there is a
222 you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
226 (when e.g. page is missing) over different types of memories.
232 message generated when writing to a missing page on file typed memories,
233 as long as the page range was write-protected before.  Such a message will
245 respectively, it may be desirable for the new page / mapping to be
263     any range of memory as long as page aligned.
266     various reasons (e.g. during split of a shmem transparent huge page).
268   - Due to a reverted meaning of soft-dirty (page clean when uffd-wp bit
277 The page will not be under track of uffd-wp async mode until the page is
279 flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set.  Trying to resolve a page fault
311 Guest async page faults, ``FOLL_NOWAIT`` and all other ``GUP*`` features work
313 page faults in the guest scheduler so those guest processes that
330 guest (``UFFDIO_ZEROCOPY`` is used if the source page was a zero page).
340 the userfault address it writes the information about the missing page
342 roughly "seeks" to that page address and continues sending all
343 remaining missing pages from that new page offset. Soon after that
346 receive the page that triggered the userfault and it'll map it as
348 was spontaneously sent by the source or if it was an urgent page
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
357 over it when receiving incoming userfaults. After sending each page of
359 sending the same page twice (in case the userfault is read by the
369 the same read(2) protocol as for the page fault notifications. The
402 ``userfaultfd``, and if a page fault occurs in that area it will be
403 delivered to the manager. The proper resolution for such page fault is
408 not get further userland page faults from the removed area. Still, the
412 Unlike userland page faults which have to be synchronous and require