migration: fix typos in qapi-schema from latest migration additions
[qemu/ar7.git] / docs / virtio-migration.txt
blobcf66458b975e834df6b43c68a2ab32db237adf7e
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,
10 for several reasons:
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
21 caveats.
24 Save state procedure
25 ====================
27 virtio core               virtio transport          virtio device
28 -----------               ----------------          -------------
30                                                     save() function registered
31                                                     via register_savevm()
32 virtio_save()                                       <----------
33              ------>      save_config()
34                           - save proxy device
35                           - save transport-specific
36                             device fields
37 - save common device
38   fields
39 - save common virtqueue
40   fields
41              ------>      save_queue()
42                           - save transport-specific
43                             virtqueue fields
44              ------>                               save_device()
45                                                    - save device-specific
46                                                      fields
47 - save subsections
48   - device endianness,
49     if changed from
50     default endianness
51   - 64 bit features, if
52     any high feature bit
53     is set
54   - virtio-1 virtqueue
55     fields, if VERSION_1
56     is set
59 Load state procedure
60 ====================
62 virtio core               virtio transport          virtio device
63 -----------               ----------------          -------------
65                                                     load() function registered
66                                                     via register_savevm()
67 virtio_load()                                       <----------
68              ------>      load_config()
69                           - load proxy device
70                           - load transport-specific
71                             device fields
72 - load common device
73   fields
74 - load common virtqueue
75   fields
76              ------>      load_queue()
77                           - load transport-specific
78                             virtqueue fields
79 - notify guest
80              ------>                               load_device()
81                                                    - load device-specific
82                                                      fields
83 - load subsections
84   - device endianness
85   - 64 bit features
86   - virtio-1 virtqueue
87     fields
88 - sanitize endianness
89 - sanitize features
90 - virtqueue index sanity
91   check
92                                                    - feature-dependent setup
95 Implications of this setup
96 ==========================
98 Devices need to be careful in their state processing during load: The
99 load_device() procedure is invoked by the core before subsections have
100 been loaded. Any code that depends on information transmitted in subsections
101 therefore has to be invoked in the device's load() function _after_
102 virtio_load() returned (like e.g. code depending on features).
104 Any extension of the state being migrated should be done in subsections
105 added to the core for compatibility reasons. If transport or device specific
106 state is added, core needs to invoke a callback from the new subsection.