jcs.org
qemu with hax to log dma reads & writes
jcs.org/2018/11/12/vfio
1=========
2Migration
3=========
4
5QEMU has code to load/save the state of the guest that it is running.
6These are two complementary operations. Saving the state just does
7that, saves the state for each device that the guest is running.
8Restoring a guest is just the opposite operation: we need to load the
9state of each device.
10
11For this to work, QEMU has to be launched with the same arguments the
12two times. I.e. it can only restore the state in one guest that has
13the same devices that the one it was saved (this last requirement can
14be relaxed a bit, but for now we can consider that configuration has
15to be exactly the same).
16
17Once that we are able to save/restore a guest, a new functionality is
18requested: migration. This means that QEMU is able to start in one
19machine and being "migrated" to another machine. I.e. being moved to
20another machine.
21
22Next was the "live migration" functionality. This is important
23because some guests run with a lot of state (specially RAM), and it
24can take a while to move all state from one machine to another. Live
25migration allows the guest to continue running while the state is
26transferred. Only while the last part of the state is transferred has
27the guest to be stopped. Typically the time that the guest is
28unresponsive during live migration is the low hundred of milliseconds
29(notice that this depends on a lot of things).
30
31Transports
32==========
33
34The migration stream is normally just a byte stream that can be passed
35over any transport.
36
37- tcp migration: do the migration using tcp sockets
38- unix migration: do the migration using unix sockets
39- exec migration: do the migration using the stdin/stdout through a process.
40- fd migration: do the migration using a file descriptor that is
41 passed to QEMU. QEMU doesn't care how this file descriptor is opened.
42
43In addition, support is included for migration using RDMA, which
44transports the page data using ``RDMA``, where the hardware takes care of
45transporting the pages, and the load on the CPU is much lower. While the
46internals of RDMA migration are a bit different, this isn't really visible
47outside the RAM migration code.
48
49All these migration protocols use the same infrastructure to
50save/restore state devices. This infrastructure is shared with the
51savevm/loadvm functionality.
52
53Debugging
54=========
55
56The migration stream can be analyzed thanks to `scripts/analyze_migration.py`.
57
58Example usage:
59
60.. code-block:: shell
61
62 $ qemu-system-x86_64
63 (qemu) migrate "exec:cat > mig"
64 $ ./scripts/analyze_migration.py -f mig
65 {
66 "ram (3)": {
67 "section sizes": {
68 "pc.ram": "0x0000000008000000",
69 ...
70
71See also ``analyze_migration.py -h`` help for more options.
72
73Common infrastructure
74=====================
75
76The files, sockets or fd's that carry the migration stream are abstracted by
77the ``QEMUFile`` type (see `migration/qemu-file.h`). In most cases this
78is connected to a subtype of ``QIOChannel`` (see `io/`).
79
80
81Saving the state of one device
82==============================
83
84For most devices, the state is saved in a single call to the migration
85infrastructure; these are *non-iterative* devices. The data for these
86devices is sent at the end of precopy migration, when the CPUs are paused.
87There are also *iterative* devices, which contain a very large amount of
88data (e.g. RAM or large tables). See the iterative device section below.
89
90General advice for device developers
91------------------------------------
92
93- The migration state saved should reflect the device being modelled rather
94 than the way your implementation works. That way if you change the implementation
95 later the migration stream will stay compatible. That model may include
96 internal state that's not directly visible in a register.
97
98- When saving a migration stream the device code may walk and check
99 the state of the device. These checks might fail in various ways (e.g.
100 discovering internal state is corrupt or that the guest has done something bad).
101 Consider carefully before asserting/aborting at this point, since the
102 normal response from users is that *migration broke their VM* since it had
103 apparently been running fine until then. In these error cases, the device
104 should log a message indicating the cause of error, and should consider
105 putting the device into an error state, allowing the rest of the VM to
106 continue execution.
107
108- The migration might happen at an inconvenient point,
109 e.g. right in the middle of the guest reprogramming the device, during
110 guest reboot or shutdown or while the device is waiting for external IO.
111 It's strongly preferred that migrations do not fail in this situation,
112 since in the cloud environment migrations might happen automatically to
113 VMs that the administrator doesn't directly control.
114
115- If you do need to fail a migration, ensure that sufficient information
116 is logged to identify what went wrong.
117
118- The destination should treat an incoming migration stream as hostile
119 (which we do to varying degrees in the existing code). Check that offsets
120 into buffers and the like can't cause overruns. Fail the incoming migration
121 in the case of a corrupted stream like this.
122
123- Take care with internal device state or behaviour that might become
124 migration version dependent. For example, the order of PCI capabilities
125 is required to stay constant across migration. Another example would
126 be that a special case handled by subsections (see below) might become
127 much more common if a default behaviour is changed.
128
129- The state of the source should not be changed or destroyed by the
130 outgoing migration. Migrations timing out or being failed by
131 higher levels of management, or failures of the destination host are
132 not unusual, and in that case the VM is restarted on the source.
133 Note that the management layer can validly revert the migration
134 even though the QEMU level of migration has succeeded as long as it
135 does it before starting execution on the destination.
136
137- Buses and devices should be able to explicitly specify addresses when
138 instantiated, and management tools should use those. For example,
139 when hot adding USB devices it's important to specify the ports
140 and addresses, since implicit ordering based on the command line order
141 may be different on the destination. This can result in the
142 device state being loaded into the wrong device.
143
144VMState
145-------
146
147Most device data can be described using the ``VMSTATE`` macros (mostly defined
148in ``include/migration/vmstate.h``).
149
150An example (from hw/input/pckbd.c)
151
152.. code:: c
153
154 static const VMStateDescription vmstate_kbd = {
155 .name = "pckbd",
156 .version_id = 3,
157 .minimum_version_id = 3,
158 .fields = (VMStateField[]) {
159 VMSTATE_UINT8(write_cmd, KBDState),
160 VMSTATE_UINT8(status, KBDState),
161 VMSTATE_UINT8(mode, KBDState),
162 VMSTATE_UINT8(pending, KBDState),
163 VMSTATE_END_OF_LIST()
164 }
165 };
166
167We are declaring the state with name "pckbd".
168The `version_id` is 3, and the fields are 4 uint8_t in a KBDState structure.
169We registered this with:
170
171.. code:: c
172
173 vmstate_register(NULL, 0, &vmstate_kbd, s);
174
175For devices that are `qdev` based, we can register the device in the class
176init function:
177
178.. code:: c
179
180 dc->vmsd = &vmstate_kbd_isa;
181
182The VMState macros take care of ensuring that the device data section
183is formatted portably (normally big endian) and make some compile time checks
184against the types of the fields in the structures.
185
186VMState macros can include other VMStateDescriptions to store substructures
187(see ``VMSTATE_STRUCT_``), arrays (``VMSTATE_ARRAY_``) and variable length
188arrays (``VMSTATE_VARRAY_``). Various other macros exist for special
189cases.
190
191Note that the format on the wire is still very raw; i.e. a VMSTATE_UINT32
192ends up with a 4 byte bigendian representation on the wire; in the future
193it might be possible to use a more structured format.
194
195Legacy way
196----------
197
198This way is going to disappear as soon as all current users are ported to VMSTATE;
199although converting existing code can be tricky, and thus 'soon' is relative.
200
201Each device has to register two functions, one to save the state and
202another to load the state back.
203
204.. code:: c
205
206 int register_savevm_live(const char *idstr,
207 int instance_id,
208 int version_id,
209 SaveVMHandlers *ops,
210 void *opaque);
211
212Two functions in the ``ops`` structure are the `save_state`
213and `load_state` functions. Notice that `load_state` receives a version_id
214parameter to know what state format is receiving. `save_state` doesn't
215have a version_id parameter because it always uses the latest version.
216
217Note that because the VMState macros still save the data in a raw
218format, in many cases it's possible to replace legacy code
219with a carefully constructed VMState description that matches the
220byte layout of the existing code.
221
222Changing migration data structures
223----------------------------------
224
225When we migrate a device, we save/load the state as a series
226of fields. Sometimes, due to bugs or new functionality, we need to
227change the state to store more/different information. Changing the migration
228state saved for a device can break migration compatibility unless
229care is taken to use the appropriate techniques. In general QEMU tries
230to maintain forward migration compatibility (i.e. migrating from
231QEMU n->n+1) and there are users who benefit from backward compatibility
232as well.
233
234Subsections
235-----------
236
237The most common structure change is adding new data, e.g. when adding
238a newer form of device, or adding that state that you previously
239forgot to migrate. This is best solved using a subsection.
240
241A subsection is "like" a device vmstate, but with a particularity, it
242has a Boolean function that tells if that values are needed to be sent
243or not. If this functions returns false, the subsection is not sent.
244Subsections have a unique name, that is looked for on the receiving
245side.
246
247On the receiving side, if we found a subsection for a device that we
248don't understand, we just fail the migration. If we understand all
249the subsections, then we load the state with success. There's no check
250that a subsection is loaded, so a newer QEMU that knows about a subsection
251can (with care) load a stream from an older QEMU that didn't send
252the subsection.
253
254If the new data is only needed in a rare case, then the subsection
255can be made conditional on that case and the migration will still
256succeed to older QEMUs in most cases. This is OK for data that's
257critical, but in some use cases it's preferred that the migration
258should succeed even with the data missing. To support this the
259subsection can be connected to a device property and from there
260to a versioned machine type.
261
262The 'pre_load' and 'post_load' functions on subsections are only
263called if the subsection is loaded.
264
265One important note is that the outer post_load() function is called "after"
266loading all subsections, because a newer subsection could change the same
267value that it uses. A flag, and the combination of outer pre_load and
268post_load can be used to detect whether a subsection was loaded, and to
269fall back on default behaviour when the subsection isn't present.
270
271Example:
272
273.. code:: c
274
275 static bool ide_drive_pio_state_needed(void *opaque)
276 {
277 IDEState *s = opaque;
278
279 return ((s->status & DRQ_STAT) != 0)
280 || (s->bus->error_status & BM_STATUS_PIO_RETRY);
281 }
282
283 const VMStateDescription vmstate_ide_drive_pio_state = {
284 .name = "ide_drive/pio_state",
285 .version_id = 1,
286 .minimum_version_id = 1,
287 .pre_save = ide_drive_pio_pre_save,
288 .post_load = ide_drive_pio_post_load,
289 .needed = ide_drive_pio_state_needed,
290 .fields = (VMStateField[]) {
291 VMSTATE_INT32(req_nb_sectors, IDEState),
292 VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1,
293 vmstate_info_uint8, uint8_t),
294 VMSTATE_INT32(cur_io_buffer_offset, IDEState),
295 VMSTATE_INT32(cur_io_buffer_len, IDEState),
296 VMSTATE_UINT8(end_transfer_fn_idx, IDEState),
297 VMSTATE_INT32(elementary_transfer_size, IDEState),
298 VMSTATE_INT32(packet_transfer_size, IDEState),
299 VMSTATE_END_OF_LIST()
300 }
301 };
302
303 const VMStateDescription vmstate_ide_drive = {
304 .name = "ide_drive",
305 .version_id = 3,
306 .minimum_version_id = 0,
307 .post_load = ide_drive_post_load,
308 .fields = (VMStateField[]) {
309 .... several fields ....
310 VMSTATE_END_OF_LIST()
311 },
312 .subsections = (const VMStateDescription*[]) {
313 &vmstate_ide_drive_pio_state,
314 NULL
315 }
316 };
317
318Here we have a subsection for the pio state. We only need to
319save/send this state when we are in the middle of a pio operation
320(that is what ``ide_drive_pio_state_needed()`` checks). If DRQ_STAT is
321not enabled, the values on that fields are garbage and don't need to
322be sent.
323
324Connecting subsections to properties
325------------------------------------
326
327Using a condition function that checks a 'property' to determine whether
328to send a subsection allows backward migration compatibility when
329new subsections are added, especially when combined with versioned
330machine types.
331
332For example:
333
334 a) Add a new property using ``DEFINE_PROP_BOOL`` - e.g. support-foo and
335 default it to true.
336 b) Add an entry to the ``hw_compat_`` for the previous version that sets
337 the property to false.
338 c) Add a static bool support_foo function that tests the property.
339 d) Add a subsection with a .needed set to the support_foo function
340 e) (potentially) Add an outer pre_load that sets up a default value
341 for 'foo' to be used if the subsection isn't loaded.
342
343Now that subsection will not be generated when using an older
344machine type and the migration stream will be accepted by older
345QEMU versions.
346
347Not sending existing elements
348-----------------------------
349
350Sometimes members of the VMState are no longer needed:
351
352 - removing them will break migration compatibility
353
354 - making them version dependent and bumping the version will break backward migration
355 compatibility.
356
357Adding a dummy field into the migration stream is normally the best way to preserve
358compatibility.
359
360If the field really does need to be removed then:
361
362 a) Add a new property/compatibility/function in the same way for subsections above.
363 b) replace the VMSTATE macro with the _TEST version of the macro, e.g.:
364
365 ``VMSTATE_UINT32(foo, barstruct)``
366
367 becomes
368
369 ``VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz)``
370
371 Sometime in the future when we no longer care about the ancient versions these can be killed off.
372 Note that for backward compatibility it's important to fill in the structure with
373 data that the destination will understand.
374
375Any difference in the predicates on the source and destination will end up
376with different fields being enabled and data being loaded into the wrong
377fields; for this reason conditional fields like this are very fragile.
378
379Versions
380--------
381
382Version numbers are intended for major incompatible changes to the
383migration of a device, and using them breaks backward-migration
384compatibility; in general most changes can be made by adding Subsections
385(see above) or _TEST macros (see above) which won't break compatibility.
386
387Each version is associated with a series of fields saved. The `save_state` always saves
388the state as the newer version. But `load_state` sometimes is able to
389load state from an older version.
390
391You can see that there are several version fields:
392
393- `version_id`: the maximum version_id supported by VMState for that device.
394- `minimum_version_id`: the minimum version_id that VMState is able to understand
395 for that device.
396- `minimum_version_id_old`: For devices that were not able to port to vmstate, we can
397 assign a function that knows how to read this old state. This field is
398 ignored if there is no `load_state_old` handler.
399
400VMState is able to read versions from minimum_version_id to
401version_id. And the function ``load_state_old()`` (if present) is able to
402load state from minimum_version_id_old to minimum_version_id. This
403function is deprecated and will be removed when no more users are left.
404
405There are *_V* forms of many ``VMSTATE_`` macros to load fields for version dependent fields,
406e.g.
407
408.. code:: c
409
410 VMSTATE_UINT16_V(ip_id, Slirp, 2),
411
412only loads that field for versions 2 and newer.
413
414Saving state will always create a section with the 'version_id' value
415and thus can't be loaded by any older QEMU.
416
417Massaging functions
418-------------------
419
420Sometimes, it is not enough to be able to save the state directly
421from one structure, we need to fill the correct values there. One
422example is when we are using kvm. Before saving the cpu state, we
423need to ask kvm to copy to QEMU the state that it is using. And the
424opposite when we are loading the state, we need a way to tell kvm to
425load the state for the cpu that we have just loaded from the QEMUFile.
426
427The functions to do that are inside a vmstate definition, and are called:
428
429- ``int (*pre_load)(void *opaque);``
430
431 This function is called before we load the state of one device.
432
433- ``int (*post_load)(void *opaque, int version_id);``
434
435 This function is called after we load the state of one device.
436
437- ``int (*pre_save)(void *opaque);``
438
439 This function is called before we save the state of one device.
440
441- ``int (*post_save)(void *opaque);``
442
443 This function is called after we save the state of one device
444 (even upon failure, unless the call to pre_save returned an error).
445
446Example: You can look at hpet.c, that uses the first three functions
447to massage the state that is transferred.
448
449The ``VMSTATE_WITH_TMP`` macro may be useful when the migration
450data doesn't match the stored device data well; it allows an
451intermediate temporary structure to be populated with migration
452data and then transferred to the main structure.
453
454If you use memory API functions that update memory layout outside
455initialization (i.e., in response to a guest action), this is a strong
456indication that you need to call these functions in a `post_load` callback.
457Examples of such memory API functions are:
458
459 - memory_region_add_subregion()
460 - memory_region_del_subregion()
461 - memory_region_set_readonly()
462 - memory_region_set_nonvolatile()
463 - memory_region_set_enabled()
464 - memory_region_set_address()
465 - memory_region_set_alias_offset()
466
467Iterative device migration
468--------------------------
469
470Some devices, such as RAM, Block storage or certain platform devices,
471have large amounts of data that would mean that the CPUs would be
472paused for too long if they were sent in one section. For these
473devices an *iterative* approach is taken.
474
475The iterative devices generally don't use VMState macros
476(although it may be possible in some cases) and instead use
477qemu_put_*/qemu_get_* macros to read/write data to the stream. Specialist
478versions exist for high bandwidth IO.
479
480
481An iterative device must provide:
482
483 - A ``save_setup`` function that initialises the data structures and
484 transmits a first section containing information on the device. In the
485 case of RAM this transmits a list of RAMBlocks and sizes.
486
487 - A ``load_setup`` function that initialises the data structures on the
488 destination.
489
490 - A ``save_live_pending`` function that is called repeatedly and must
491 indicate how much more data the iterative data must save. The core
492 migration code will use this to determine when to pause the CPUs
493 and complete the migration.
494
495 - A ``save_live_iterate`` function (called after ``save_live_pending``
496 when there is significant data still to be sent). It should send
497 a chunk of data until the point that stream bandwidth limits tell it
498 to stop. Each call generates one section.
499
500 - A ``save_live_complete_precopy`` function that must transmit the
501 last section for the device containing any remaining data.
502
503 - A ``load_state`` function used to load sections generated by
504 any of the save functions that generate sections.
505
506 - ``cleanup`` functions for both save and load that are called
507 at the end of migration.
508
509Note that the contents of the sections for iterative migration tend
510to be open-coded by the devices; care should be taken in parsing
511the results and structuring the stream to make them easy to validate.
512
513Device ordering
514---------------
515
516There are cases in which the ordering of device loading matters; for
517example in some systems where a device may assert an interrupt during loading,
518if the interrupt controller is loaded later then it might lose the state.
519
520Some ordering is implicitly provided by the order in which the machine
521definition creates devices, however this is somewhat fragile.
522
523The ``MigrationPriority`` enum provides a means of explicitly enforcing
524ordering. Numerically higher priorities are loaded earlier.
525The priority is set by setting the ``priority`` field of the top level
526``VMStateDescription`` for the device.
527
528Stream structure
529================
530
531The stream tries to be word and endian agnostic, allowing migration between hosts
532of different characteristics running the same VM.
533
534 - Header
535
536 - Magic
537 - Version
538 - VM configuration section
539
540 - Machine type
541 - Target page bits
542 - List of sections
543 Each section contains a device, or one iteration of a device save.
544
545 - section type
546 - section id
547 - ID string (First section of each device)
548 - instance id (First section of each device)
549 - version id (First section of each device)
550 - <device data>
551 - Footer mark
552 - EOF mark
553 - VM Description structure
554 Consisting of a JSON description of the contents for analysis only
555
556The ``device data`` in each section consists of the data produced
557by the code described above. For non-iterative devices they have a single
558section; iterative devices have an initial and last section and a set
559of parts in between.
560Note that there is very little checking by the common code of the integrity
561of the ``device data`` contents, that's up to the devices themselves.
562The ``footer mark`` provides a little bit of protection for the case where
563the receiving side reads more or less data than expected.
564
565The ``ID string`` is normally unique, having been formed from a bus name
566and device address, PCI devices and storage devices hung off PCI controllers
567fit this pattern well. Some devices are fixed single instances (e.g. "pc-ram").
568Others (especially either older devices or system devices which for
569some reason don't have a bus concept) make use of the ``instance id``
570for otherwise identically named devices.
571
572Return path
573-----------
574
575Only a unidirectional stream is required for normal migration, however a
576``return path`` can be created when bidirectional communication is desired.
577This is primarily used by postcopy, but is also used to return a success
578flag to the source at the end of migration.
579
580``qemu_file_get_return_path(QEMUFile* fwdpath)`` gives the QEMUFile* for the return
581path.
582
583 Source side
584
585 Forward path - written by migration thread
586 Return path - opened by main thread, read by return-path thread
587
588 Destination side
589
590 Forward path - read by main thread
591 Return path - opened by main thread, written by main thread AND postcopy
592 thread (protected by rp_mutex)
593
594Postcopy
595========
596
597'Postcopy' migration is a way to deal with migrations that refuse to converge
598(or take too long to converge) its plus side is that there is an upper bound on
599the amount of migration traffic and time it takes, the down side is that during
600the postcopy phase, a failure of *either* side or the network connection causes
601the guest to be lost.
602
603In postcopy the destination CPUs are started before all the memory has been
604transferred, and accesses to pages that are yet to be transferred cause
605a fault that's translated by QEMU into a request to the source QEMU.
606
607Postcopy can be combined with precopy (i.e. normal migration) so that if precopy
608doesn't finish in a given time the switch is made to postcopy.
609
610Enabling postcopy
611-----------------
612
613To enable postcopy, issue this command on the monitor (both source and
614destination) prior to the start of migration:
615
616``migrate_set_capability postcopy-ram on``
617
618The normal commands are then used to start a migration, which is still
619started in precopy mode. Issuing:
620
621``migrate_start_postcopy``
622
623will now cause the transition from precopy to postcopy.
624It can be issued immediately after migration is started or any
625time later on. Issuing it after the end of a migration is harmless.
626
627Blocktime is a postcopy live migration metric, intended to show how
628long the vCPU was in state of interruptable sleep due to pagefault.
629That metric is calculated both for all vCPUs as overlapped value, and
630separately for each vCPU. These values are calculated on destination
631side. To enable postcopy blocktime calculation, enter following
632command on destination monitor:
633
634``migrate_set_capability postcopy-blocktime on``
635
636Postcopy blocktime can be retrieved by query-migrate qmp command.
637postcopy-blocktime value of qmp command will show overlapped blocking
638time for all vCPU, postcopy-vcpu-blocktime will show list of blocking
639time per vCPU.
640
641.. note::
642 During the postcopy phase, the bandwidth limits set using
643 ``migrate_set_speed`` is ignored (to avoid delaying requested pages that
644 the destination is waiting for).
645
646Postcopy device transfer
647------------------------
648
649Loading of device data may cause the device emulation to access guest RAM
650that may trigger faults that have to be resolved by the source, as such
651the migration stream has to be able to respond with page data *during* the
652device load, and hence the device data has to be read from the stream completely
653before the device load begins to free the stream up. This is achieved by
654'packaging' the device data into a blob that's read in one go.
655
656Source behaviour
657----------------
658
659Until postcopy is entered the migration stream is identical to normal
660precopy, except for the addition of a 'postcopy advise' command at
661the beginning, to tell the destination that postcopy might happen.
662When postcopy starts the source sends the page discard data and then
663forms the 'package' containing:
664
665 - Command: 'postcopy listen'
666 - The device state
667
668 A series of sections, identical to the precopy streams device state stream
669 containing everything except postcopiable devices (i.e. RAM)
670 - Command: 'postcopy run'
671
672The 'package' is sent as the data part of a Command: ``CMD_PACKAGED``, and the
673contents are formatted in the same way as the main migration stream.
674
675During postcopy the source scans the list of dirty pages and sends them
676to the destination without being requested (in much the same way as precopy),
677however when a page request is received from the destination, the dirty page
678scanning restarts from the requested location. This causes requested pages
679to be sent quickly, and also causes pages directly after the requested page
680to be sent quickly in the hope that those pages are likely to be used
681by the destination soon.
682
683Destination behaviour
684---------------------
685
686Initially the destination looks the same as precopy, with a single thread
687reading the migration stream; the 'postcopy advise' and 'discard' commands
688are processed to change the way RAM is managed, but don't affect the stream
689processing.
690
691::
692
693 ------------------------------------------------------------------------------
694 1 2 3 4 5 6 7
695 main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN )
696 thread | |
697 | (page request)
698 | \___
699 v \
700 listen thread: --- page -- page -- page -- page -- page --
701
702 a b c
703 ------------------------------------------------------------------------------
704
705- On receipt of ``CMD_PACKAGED`` (1)
706
707 All the data associated with the package - the ( ... ) section in the diagram -
708 is read into memory, and the main thread recurses into qemu_loadvm_state_main
709 to process the contents of the package (2) which contains commands (3,6) and
710 devices (4...)
711
712- On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package)
713
714 a new thread (a) is started that takes over servicing the migration stream,
715 while the main thread carries on loading the package. It loads normal
716 background page data (b) but if during a device load a fault happens (5)
717 the returned page (c) is loaded by the listen thread allowing the main
718 threads device load to carry on.
719
720- The last thing in the ``CMD_PACKAGED`` is a 'RUN' command (6)
721
722 letting the destination CPUs start running. At the end of the
723 ``CMD_PACKAGED`` (7) the main thread returns to normal running behaviour and
724 is no longer used by migration, while the listen thread carries on servicing
725 page data until the end of migration.
726
727Postcopy states
728---------------
729
730Postcopy moves through a series of states (see postcopy_state) from
731ADVISE->DISCARD->LISTEN->RUNNING->END
732
733 - Advise
734
735 Set at the start of migration if postcopy is enabled, even
736 if it hasn't had the start command; here the destination
737 checks that its OS has the support needed for postcopy, and performs
738 setup to ensure the RAM mappings are suitable for later postcopy.
739 The destination will fail early in migration at this point if the
740 required OS support is not present.
741 (Triggered by reception of POSTCOPY_ADVISE command)
742
743 - Discard
744
745 Entered on receipt of the first 'discard' command; prior to
746 the first Discard being performed, hugepages are switched off
747 (using madvise) to ensure that no new huge pages are created
748 during the postcopy phase, and to cause any huge pages that
749 have discards on them to be broken.
750
751 - Listen
752
753 The first command in the package, POSTCOPY_LISTEN, switches
754 the destination state to Listen, and starts a new thread
755 (the 'listen thread') which takes over the job of receiving
756 pages off the migration stream, while the main thread carries
757 on processing the blob. With this thread able to process page
758 reception, the destination now 'sensitises' the RAM to detect
759 any access to missing pages (on Linux using the 'userfault'
760 system).
761
762 - Running
763
764 POSTCOPY_RUN causes the destination to synchronise all
765 state and start the CPUs and IO devices running. The main
766 thread now finishes processing the migration package and
767 now carries on as it would for normal precopy migration
768 (although it can't do the cleanup it would do as it
769 finishes a normal migration).
770
771 - End
772
773 The listen thread can now quit, and perform the cleanup of migration
774 state, the migration is now complete.
775
776Source side page maps
777---------------------
778
779The source side keeps two bitmaps during postcopy; 'the migration bitmap'
780and 'unsent map'. The 'migration bitmap' is basically the same as in
781the precopy case, and holds a bit to indicate that page is 'dirty' -
782i.e. needs sending. During the precopy phase this is updated as the CPU
783dirties pages, however during postcopy the CPUs are stopped and nothing
784should dirty anything any more.
785
786The 'unsent map' is used for the transition to postcopy. It is a bitmap that
787has a bit cleared whenever a page is sent to the destination, however during
788the transition to postcopy mode it is combined with the migration bitmap
789to form a set of pages that:
790
791 a) Have been sent but then redirtied (which must be discarded)
792 b) Have not yet been sent - which also must be discarded to cause any
793 transparent huge pages built during precopy to be broken.
794
795Note that the contents of the unsentmap are sacrificed during the calculation
796of the discard set and thus aren't valid once in postcopy. The dirtymap
797is still valid and is used to ensure that no page is sent more than once. Any
798request for a page that has already been sent is ignored. Duplicate requests
799such as this can happen as a page is sent at about the same time the
800destination accesses it.
801
802Postcopy with hugepages
803-----------------------
804
805Postcopy now works with hugetlbfs backed memory:
806
807 a) The linux kernel on the destination must support userfault on hugepages.
808 b) The huge-page configuration on the source and destination VMs must be
809 identical; i.e. RAMBlocks on both sides must use the same page size.
810 c) Note that ``-mem-path /dev/hugepages`` will fall back to allocating normal
811 RAM if it doesn't have enough hugepages, triggering (b) to fail.
812 Using ``-mem-prealloc`` enforces the allocation using hugepages.
813 d) Care should be taken with the size of hugepage used; postcopy with 2MB
814 hugepages works well, however 1GB hugepages are likely to be problematic
815 since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps link,
816 and until the full page is transferred the destination thread is blocked.
817
818Postcopy with shared memory
819---------------------------
820
821Postcopy migration with shared memory needs explicit support from the other
822processes that share memory and from QEMU. There are restrictions on the type of
823memory that userfault can support shared.
824
825The Linux kernel userfault support works on `/dev/shm` memory and on `hugetlbfs`
826(although the kernel doesn't provide an equivalent to `madvise(MADV_DONTNEED)`
827for hugetlbfs which may be a problem in some configurations).
828
829The vhost-user code in QEMU supports clients that have Postcopy support,
830and the `vhost-user-bridge` (in `tests/`) and the DPDK package have changes
831to support postcopy.
832
833The client needs to open a userfaultfd and register the areas
834of memory that it maps with userfault. The client must then pass the
835userfaultfd back to QEMU together with a mapping table that allows
836fault addresses in the clients address space to be converted back to
837RAMBlock/offsets. The client's userfaultfd is added to the postcopy
838fault-thread and page requests are made on behalf of the client by QEMU.
839QEMU performs 'wake' operations on the client's userfaultfd to allow it
840to continue after a page has arrived.
841
842.. note::
843 There are two future improvements that would be nice:
844 a) Some way to make QEMU ignorant of the addresses in the clients
845 address space
846 b) Avoiding the need for QEMU to perform ufd-wake calls after the
847 pages have arrived
848
849Retro-fitting postcopy to existing clients is possible:
850 a) A mechanism is needed for the registration with userfault as above,
851 and the registration needs to be coordinated with the phases of
852 postcopy. In vhost-user extra messages are added to the existing
853 control channel.
854 b) Any thread that can block due to guest memory accesses must be
855 identified and the implication understood; for example if the
856 guest memory access is made while holding a lock then all other
857 threads waiting for that lock will also be blocked.
858
859Firmware
860========
861
862Migration migrates the copies of RAM and ROM, and thus when running
863on the destination it includes the firmware from the source. Even after
864resetting a VM, the old firmware is used. Only once QEMU has been restarted
865is the new firmware in use.
866
867- Changes in firmware size can cause changes in the required RAMBlock size
868 to hold the firmware and thus migration can fail. In practice it's best
869 to pad firmware images to convenient powers of 2 with plenty of space
870 for growth.
871
872- Care should be taken with device emulation code so that newer
873 emulation code can work with older firmware to allow forward migration.
874
875- Care should be taken with newer firmware so that backward migration
876 to older systems with older device emulation code will work.
877
878In some cases it may be best to tie specific firmware versions to specific
879versioned machine types to cut down on the combinations that will need
880support. This is also useful when newer versions of firmware outgrow
881the padding.
882