Lines Matching refs:in

23    registered in the userfaultfd that allows userland to efficiently
25    memory in the background
28 management of mremap/mprotect is that the userfaults in all their
29 operations never involve heavyweight structures like vmas (in fact the
58 be invoked (if present in the returned uffdio_api.ioctls bitmask) to
59 register a memory range in the userfaultfd by setting the
71 address space in the background (to add or potentially also remove
73 could be triggering just before userland maps in the background the
80 UFFDIO_COPY. They're atomic as in guaranteeing that nothing can see an
89 all of its memory residing on a different node in the cloud. The
91 KVM kernel code had to be modified in order to add postcopy live
95 just fine in combination with userfaults. Userfaults trigger async
96 page faults in the guest scheduler so those guest processes that
97 aren't waiting for userfaults (i.e. network bound) can keep running in
101 just before starting postcopy live migration, in order to avoid
105 single bidirectional socket but in the future two different sockets
109 The QEMU in the source node writes all pages that it knows are missing
110 in the destination node, into the socket, and the migration thread of
111 the QEMU running in the destination node runs UFFDIO_COPY|ZEROPAGE
112 ioctls on the userfaultfd in order to map the received pages into the
115 A different postcopy thread in the destination node listens with
116 poll() to the userfaultfd in parallel. When a POLLIN event is
118 the userfaultfd and receives the fault address (or -EAGAIN in case the
122 After the QEMU postcopy thread (running in the destination node) gets
128 migration thread in the QEMU running in the destination node will
134 By the time the userfaults start, the QEMU in the destination node
136 migration around and a single per-page bitmap has to be maintained in
137 the QEMU running in the source node to know which pages are still
138 missing in the destination node. The bitmap in the source node is
139 checked to find which missing pages to send in round robin and we seek
142 sending the same page twice (in case the userfault is read by the
143 postcopy thread just before UFFDIO_COPY|ZEROPAGE runs in the migration