Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
[qemu.git] / docs / migration.txt
1 = Migration =
2
3 QEMU has code to load/save the state of the guest that it is running.
4 These are two complementary operations.  Saving the state just does
5 that, saves the state for each device that the guest is running.
6 Restoring a guest is just the opposite operation: we need to load the
7 state of each device.
8
9 For this to work, QEMU has to be launched with the same arguments the
10 two times.  I.e. it can only restore the state in one guest that has
11 the same devices that the one it was saved (this last requirement can
12 be relaxed a bit, but for now we can consider that configuration has
13 to be exactly the same).
14
15 Once that we are able to save/restore a guest, a new functionality is
16 requested: migration.  This means that QEMU is able to start in one
17 machine and being "migrated" to another machine.  I.e. being moved to
18 another machine.
19
20 Next was the "live migration" functionality.  This is important
21 because some guests run with a lot of state (specially RAM), and it
22 can take a while to move all state from one machine to another.  Live
23 migration allows the guest to continue running while the state is
24 transferred.  Only while the last part of the state is transferred has
25 the guest to be stopped.  Typically the time that the guest is
26 unresponsive during live migration is the low hundred of milliseconds
27 (notice that this depends on a lot of things).
28
29 === Types of migration ===
30
31 Now that we have talked about live migration, there are several ways
32 to do migration:
33
34 - tcp migration: do the migration using tcp sockets
35 - unix migration: do the migration using unix sockets
36 - exec migration: do the migration using the stdin/stdout through a process.
37 - fd migration: do the migration using an file descriptor that is
38   passed to QEMU.  QEMU doesn't care how this file descriptor is opened.
39
40 All these four migration protocols use the same infrastructure to
41 save/restore state devices.  This infrastructure is shared with the
42 savevm/loadvm functionality.
43
44 === State Live Migration ===
45
46 This is used for RAM and block devices.  It is not yet ported to vmstate.
47 <Fill more information here>
48
49 === What is the common infrastructure ===
50
51 QEMU uses a QEMUFile abstraction to be able to do migration.  Any type
52 of migration that wants to use QEMU infrastructure has to create a
53 QEMUFile with:
54
55 QEMUFile *qemu_fopen_ops(void *opaque,
56                          QEMUFilePutBufferFunc *put_buffer,
57                          QEMUFileGetBufferFunc *get_buffer,
58                          QEMUFileCloseFunc *close);
59
60 The functions have the following functionality:
61
62 This function writes a chunk of data to a file at the given position.
63 The pos argument can be ignored if the file is only used for
64 streaming.  The handler should try to write all of the data it can.
65
66 typedef int (QEMUFilePutBufferFunc)(void *opaque, const uint8_t *buf,
67                                     int64_t pos, int size);
68
69 Read a chunk of data from a file at the given position.  The pos argument
70 can be ignored if the file is only be used for streaming.  The number of
71 bytes actually read should be returned.
72
73 typedef int (QEMUFileGetBufferFunc)(void *opaque, uint8_t *buf,
74                                     int64_t pos, int size);
75
76 Close a file and return an error code.
77
78 typedef int (QEMUFileCloseFunc)(void *opaque);
79
80 You can use any internal state that you need using the opaque void *
81 pointer that is passed to all functions.
82
83 The important functions for us are put_buffer()/get_buffer() that
84 allow to write/read a buffer into the QEMUFile.
85
86 === How to save the state of one device ===
87
88 The state of a device is saved using intermediate buffers.  There are
89 some helper functions to assist this saving.
90
91 There is a new concept that we have to explain here: device state
92 version.  When we migrate a device, we save/load the state as a series
93 of fields.  Some times, due to bugs or new functionality, we need to
94 change the state to store more/different information.  We use the
95 version to identify each time that we do a change.  Each version is
96 associated with a series of fields saved.  The save_state always saves
97 the state as the newer version.  But load_state sometimes is able to
98 load state from an older version.
99
100 === Legacy way ===
101
102 This way is going to disappear as soon as all current users are ported to VMSTATE.
103
104 Each device has to register two functions, one to save the state and
105 another to load the state back.
106
107 int register_savevm(DeviceState *dev,
108                     const char *idstr,
109                     int instance_id,
110                     int version_id,
111                     SaveStateHandler *save_state,
112                     LoadStateHandler *load_state,
113                     void *opaque);
114
115 typedef void SaveStateHandler(QEMUFile *f, void *opaque);
116 typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
117
118 The important functions for the device state format are the save_state
119 and load_state.  Notice that load_state receives a version_id
120 parameter to know what state format is receiving.  save_state doesn't
121 have a version_id parameter because it always uses the latest version.
122
123 === VMState ===
124
125 The legacy way of saving/loading state of the device had the problem
126 that we have to maintain two functions in sync.  If we did one change
127 in one of them and not in the other, we would get a failed migration.
128
129 VMState changed the way that state is saved/loaded.  Instead of using
130 a function to save the state and another to load it, it was changed to
131 a declarative way of what the state consisted of.  Now VMState is able
132 to interpret that definition to be able to load/save the state.  As
133 the state is declared only once, it can't go out of sync in the
134 save/load functions.
135
136 An example (from hw/input/pckbd.c)
137
138 static const VMStateDescription vmstate_kbd = {
139     .name = "pckbd",
140     .version_id = 3,
141     .minimum_version_id = 3,
142     .minimum_version_id_old = 3,
143     .fields      = (VMStateField []) {
144         VMSTATE_UINT8(write_cmd, KBDState),
145         VMSTATE_UINT8(status, KBDState),
146         VMSTATE_UINT8(mode, KBDState),
147         VMSTATE_UINT8(pending, KBDState),
148         VMSTATE_END_OF_LIST()
149     }
150 };
151
152 We are declaring the state with name "pckbd".
153 The version_id is 3, and the fields are 4 uint8_t in a KBDState structure.
154 We registered this with:
155
156     vmstate_register(NULL, 0, &vmstate_kbd, s);
157
158 Note: talk about how vmstate <-> qdev interact, and what the instance ids mean.
159
160 You can search for VMSTATE_* macros for lots of types used in QEMU in
161 include/hw/hw.h.
162
163 === More about versions ===
164
165 You can see that there are several version fields:
166
167 - version_id: the maximum version_id supported by VMState for that device.
168 - minimum_version_id: the minimum version_id that VMState is able to understand
169   for that device.
170 - minimum_version_id_old: For devices that were not able to port to vmstate, we can
171   assign a function that knows how to read this old state.
172
173 So, VMState is able to read versions from minimum_version_id to
174 version_id.  And the function load_state_old() is able to load state
175 from minimum_version_id_old to minimum_version_id.  This function is
176 deprecated and will be removed when no more users are left.
177
178 ===  Massaging functions ===
179
180 Sometimes, it is not enough to be able to save the state directly
181 from one structure, we need to fill the correct values there.  One
182 example is when we are using kvm.  Before saving the cpu state, we
183 need to ask kvm to copy to QEMU the state that it is using.  And the
184 opposite when we are loading the state, we need a way to tell kvm to
185 load the state for the cpu that we have just loaded from the QEMUFile.
186
187 The functions to do that are inside a vmstate definition, and are called:
188
189 - int (*pre_load)(void *opaque);
190
191   This function is called before we load the state of one device.
192
193 - int (*post_load)(void *opaque, int version_id);
194
195   This function is called after we load the state of one device.
196
197 - void (*pre_save)(void *opaque);
198
199   This function is called before we save the state of one device.
200
201 Example: You can look at hpet.c, that uses the three function to
202          massage the state that is transferred.
203
204 If you use memory API functions that update memory layout outside
205 initialization (i.e., in response to a guest action), this is a strong
206 indication that you need to call these functions in a post_load callback.
207 Examples of such memory API functions are:
208
209   - memory_region_add_subregion()
210   - memory_region_del_subregion()
211   - memory_region_set_readonly()
212   - memory_region_set_enabled()
213   - memory_region_set_address()
214   - memory_region_set_alias_offset()
215
216 === Subsections ===
217
218 The use of version_id allows to be able to migrate from older versions
219 to newer versions of a device.  But not the other way around.  This
220 makes very complicated to fix bugs in stable branches.  If we need to
221 add anything to the state to fix a bug, we have to disable migration
222 to older versions that don't have that bug-fix (i.e. a new field).
223
224 But sometimes, that bug-fix is only needed sometimes, not always.  For
225 instance, if the device is in the middle of a DMA operation, it is
226 using a specific functionality, ....
227
228 It is impossible to create a way to make migration from any version to
229 any other version to work.  But we can do better than only allowing
230 migration from older versions to newer ones.  For that fields that are
231 only needed sometimes, we add the idea of subsections.  A subsection
232 is "like" a device vmstate, but with a particularity, it has a Boolean
233 function that tells if that values are needed to be sent or not.  If
234 this functions returns false, the subsection is not sent.
235
236 On the receiving side, if we found a subsection for a device that we
237 don't understand, we just fail the migration.  If we understand all
238 the subsections, then we load the state with success.
239
240 One important note is that the post_load() function is called "after"
241 loading all subsections, because a newer subsection could change same
242 value that it uses.
243
244 Example:
245
246 static bool ide_drive_pio_state_needed(void *opaque)
247 {
248     IDEState *s = opaque;
249
250     return ((s->status & DRQ_STAT) != 0)
251         || (s->bus->error_status & BM_STATUS_PIO_RETRY);
252 }
253
254 const VMStateDescription vmstate_ide_drive_pio_state = {
255     .name = "ide_drive/pio_state",
256     .version_id = 1,
257     .minimum_version_id = 1,
258     .minimum_version_id_old = 1,
259     .pre_save = ide_drive_pio_pre_save,
260     .post_load = ide_drive_pio_post_load,
261     .fields      = (VMStateField []) {
262         VMSTATE_INT32(req_nb_sectors, IDEState),
263         VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1,
264                              vmstate_info_uint8, uint8_t),
265         VMSTATE_INT32(cur_io_buffer_offset, IDEState),
266         VMSTATE_INT32(cur_io_buffer_len, IDEState),
267         VMSTATE_UINT8(end_transfer_fn_idx, IDEState),
268         VMSTATE_INT32(elementary_transfer_size, IDEState),
269         VMSTATE_INT32(packet_transfer_size, IDEState),
270         VMSTATE_END_OF_LIST()
271     }
272 };
273
274 const VMStateDescription vmstate_ide_drive = {
275     .name = "ide_drive",
276     .version_id = 3,
277     .minimum_version_id = 0,
278     .minimum_version_id_old = 0,
279     .post_load = ide_drive_post_load,
280     .fields      = (VMStateField []) {
281         .... several fields ....
282         VMSTATE_END_OF_LIST()
283     },
284     .subsections = (VMStateSubsection []) {
285         {
286             .vmsd = &vmstate_ide_drive_pio_state,
287             .needed = ide_drive_pio_state_needed,
288         }, {
289             /* empty */
290         }
291     }
292 };
293
294 Here we have a subsection for the pio state.  We only need to
295 save/send this state when we are in the middle of a pio operation
296 (that is what ide_drive_pio_state_needed() checks).  If DRQ_STAT is
297 not enabled, the values on that fields are garbage and don't need to
298 be sent.