1 Virtio devices and migration
2 ============================
4 Copyright 2015 IBM Corp.
6 This work is licensed under the terms of the GNU GPL, version 2 or later. See
7 the COPYING file in the top-level directory.
9 Saving and restoring the state of virtio devices is a bit of a twisty maze,
11 - state is distributed between several parts:
12 - virtio core, for common fields like features, number of queues, ...
13 - virtio transport (pci, ccw, ...), for the different proxy devices and
14 transport specific state (msix vectors, indicators, ...)
15 - virtio device (net, blk, ...), for the different device types and their
16 state (mac address, request queue, ...)
17 - most fields are saved via the stream interface; subsequently, subsections
18 have been added to make cross-version migration possible
20 This file attempts to document the current procedure and point out some
27 virtio core virtio transport virtio device
28 ----------- ---------------- -------------
30 save() function registered
31 via VMState wrapper on
33 virtio_save() <----------
36 - save transport-specific
40 - save common virtqueue
43 - save transport-specific
46 - save device-specific
63 virtio core virtio transport virtio device
64 ----------- ---------------- -------------
66 load() function registered
67 via VMState wrapper on
69 virtio_load() <----------
72 - load transport-specific
76 - load common virtqueue
79 - load transport-specific
83 - load device-specific
92 - virtqueue index sanity
94 - feature-dependent setup
97 Implications of this setup
98 ==========================
100 Devices need to be careful in their state processing during load: The
101 load_device() procedure is invoked by the core before subsections have
102 been loaded. Any code that depends on information transmitted in subsections
103 therefore has to be invoked in the device's load() function _after_
104 virtio_load() returned (like e.g. code depending on features).
106 Any extension of the state being migrated should be done in subsections
107 added to the core for compatibility reasons. If transport or device specific
108 state is added, core needs to invoke a callback from the new subsection.