Lines Matching refs:page
88 on processing the blob. With this thread able to process page
112 the migration stream has to be able to respond with page data *during* the
123 When postcopy starts the source sends the page discard data and then
138 however when a page request is received from the destination, the dirty page
140 to be sent quickly, and also causes pages directly after the requested page
158 | (page request)
161 listen thread: --- page -- page -- page -- page -- page --
177 background page data (b) but if during a device load a fault happens (5)
178 the returned page (c) is loaded by the listen thread allowing the main
186 page data until the end of migration.
188 Source side page bitmap
192 where each of the bit to indicate that page is 'dirty' - i.e. needs
238 running, and it will not be impacted from any page access to pages that
241 thread will be halted waiting for the page to be migrated, it means it can
245 configurations of the guest. For example, when with async page fault
255 b) The huge-page configuration on the source and destination VMs must be
256 identical; i.e. RAMBlocks on both sides must use the same page size.
263 and until the full page is transferred the destination thread is blocked.
285 fault-thread and page requests are made on behalf of the client by QEMU.
287 to continue after a page has arrived.
310 allows urgent pages (those got page fault requested from destination QEMU
312 the background migration channel. Anyone who cares about latencies of page