Lines Matching full:that

7 'Postcopy' migration is a way to deal with migrations that refuse to converge
8 (or take too long to converge) its plus side is that there is an upper bound on
9 the amount of migration traffic and time it takes, the down side is that during
13 transferred, and accesses to pages that are yet to be transferred cause
14 a fault that's translated by QEMU into a request to the source QEMU.
16 Postcopy can be combined with precopy (i.e. normal migration) so that if precopy
38 That metric is calculated both for all vCPUs as overlapped value, and
52   ``migrate_set_parameter`` is ignored (to avoid delaying requested pages that
68     checks that its OS has the support needed for postcopy, and performs
78     (using madvise) to ensure that no new huge pages are created
79     during the postcopy phase, and to cause any huge pages that
111 that may trigger faults that have to be resolved by the source, as such
115 'packaging' the device data into a blob that's read in one go.
122 the beginning, to tell the destination that postcopy might happen.
141 to be sent quickly in the hope that those pages are likely to be used
175    a new thread (a) is started that takes over servicing the migration stream,
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
257   c) Note that ``-mem-path /dev/hugepages``  will fall back to allocating normal
269 processes that share memory and from QEMU. There are restrictions on the type of
270 memory that userfault can support shared.
276 The vhost-user code in QEMU supports clients that have Postcopy support,
281 of memory that it maps with userfault.  The client must then pass the
282 userfaultfd back to QEMU together with a mapping table that allows
290   There are two future improvements that would be nice:
301   b) Any thread that can block due to guest memory accesses must be
304      threads waiting for that lock will also be blocked.