mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: Convert migration.txt to rst

Browse Source 
Mostly just manual conversion with very minor fixes.

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
This commit is contained in:
Dr. David Alan Gilbert 2017-12-15 15:45:07 +00:00 committed by Juan Quintela
parent 9102d27e33
commit 2e3c8f8dbd
1 changed files with 237 additions and 213 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

292
docs/devel/migration.txt → docs/devel/migration.rst
View File

@ -1,4 +1,6 @@
= Migration = =========
Migration
=========
QEMU has code to load/save the state of the guest that it is running. QEMU has code to load/save the state of the guest that it is running.
These are two complementary operations. Saving the state just does These are two complementary operations. Saving the state just does
@ -26,7 +28,8 @@ the guest to be stopped. Typically the time that the guest is
unresponsive during live migration is the low hundred of milliseconds unresponsive during live migration is the low hundred of milliseconds
(notice that this depends on a lot of things). (notice that this depends on a lot of things).
=== Types of migration === Types of migration
==================
Now that we have talked about live migration, there are several ways Now that we have talked about live migration, there are several ways
to do migration: to do migration:
@ -41,49 +44,21 @@ All these four migration protocols use the same infrastructure to
save/restore state devices. This infrastructure is shared with the save/restore state devices. This infrastructure is shared with the
savevm/loadvm functionality. savevm/loadvm functionality.
=== State Live Migration === State Live Migration
====================
This is used for RAM and block devices. It is not yet ported to vmstate. This is used for RAM and block devices. It is not yet ported to vmstate.
<Fill more information here> <Fill more information here>
=== What is the common infrastructure === Common infrastructure
=====================
QEMU uses a QEMUFile abstraction to be able to do migration. Any type The files, sockets or fd's that carry the migration stream are abstracted by
of migration that wants to use QEMU infrastructure has to create a the ``QEMUFile`` type (see `migration/qemu-file.h`). In most cases this
QEMUFile with: is connected to a subtype of ``QIOChannel`` (see `io/`).
QEMUFile *qemu_fopen_ops(void *opaque, Saving the state of one device
QEMUFilePutBufferFunc *put_buffer, ==============================
QEMUFileGetBufferFunc *get_buffer,
QEMUFileCloseFunc *close);
The functions have the following functionality:
This function writes a chunk of data to a file at the given position.
The pos argument can be ignored if the file is only used for
streaming. The handler should try to write all of the data it can.
typedef int (QEMUFilePutBufferFunc)(void *opaque, const uint8_t *buf,
int64_t pos, int size);
Read a chunk of data from a file at the given position. The pos argument
can be ignored if the file is only be used for streaming. The number of
bytes actually read should be returned.
typedef int (QEMUFileGetBufferFunc)(void *opaque, uint8_t *buf,
int64_t pos, int size);
Close a file and return an error code.
typedef int (QEMUFileCloseFunc)(void *opaque);
You can use any internal state that you need using the opaque void *
pointer that is passed to all functions.
The important functions for us are put_buffer()/get_buffer() that
allow to write/read a buffer into the QEMUFile.
=== How to save the state of one device ===
The state of a device is saved using intermediate buffers. There are The state of a device is saved using intermediate buffers. There are
some helper functions to assist this saving. some helper functions to assist this saving.
@ -93,18 +68,21 @@ version. When we migrate a device, we save/load the state as a series
of fields. Some times, due to bugs or new functionality, we need to of fields. Some times, due to bugs or new functionality, we need to
change the state to store more/different information. We use the change the state to store more/different information. We use the
version to identify each time that we do a change. Each version is version to identify each time that we do a change. Each version is
associated with a series of fields saved. The save_state always saves associated with a series of fields saved. The `save_state` always saves
the state as the newer version. But load_state sometimes is able to the state as the newer version. But `load_state` sometimes is able to
load state from an older version. load state from an older version.
=== Legacy way === Legacy way
----------
This way is going to disappear as soon as all current users are ported to VMSTATE. This way is going to disappear as soon as all current users are ported to VMSTATE.
Each device has to register two functions, one to save the state and Each device has to register two functions, one to save the state and
another to load the state back. another to load the state back.
int register_savevm(DeviceState *dev, .. code:: c
int register_savevm(DeviceState *dev,
const char *idstr, const char *idstr,
int instance_id, int instance_id,
int version_id, int version_id,
@ -112,15 +90,16 @@ int register_savevm(DeviceState *dev,
LoadStateHandler *load_state, LoadStateHandler *load_state,
void *opaque); void *opaque);
typedef void SaveStateHandler(QEMUFile *f, void *opaque); typedef void SaveStateHandler(QEMUFile *f, void *opaque);
typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id); typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
The important functions for the device state format are the save_state The important functions for the device state format are the `save_state`
and load_state. Notice that load_state receives a version_id and `load_state`. Notice that `load_state` receives a version_id
parameter to know what state format is receiving. save_state doesn't parameter to know what state format is receiving. `save_state` doesn't
have a version_id parameter because it always uses the latest version. have a version_id parameter because it always uses the latest version.
=== VMState === VMState
-------
The legacy way of saving/loading state of the device had the problem The legacy way of saving/loading state of the device had the problem
that we have to maintain two functions in sync. If we did one change that we have to maintain two functions in sync. If we did one change
@ -135,7 +114,9 @@ save/load functions.
An example (from hw/input/pckbd.c) An example (from hw/input/pckbd.c)
static const VMStateDescription vmstate_kbd = { .. code:: c
static const VMStateDescription vmstate_kbd = {
.name = "pckbd", .name = "pckbd",
.version_id = 3, .version_id = 3,
.minimum_version_id = 3, .minimum_version_id = 3,
@ -146,20 +127,23 @@ static const VMStateDescription vmstate_kbd = {
VMSTATE_UINT8(pending, KBDState), VMSTATE_UINT8(pending, KBDState),
VMSTATE_END_OF_LIST() VMSTATE_END_OF_LIST()
} }
}; };
We are declaring the state with name "pckbd". We are declaring the state with name "pckbd".
The version_id is 3, and the fields are 4 uint8_t in a KBDState structure. The `version_id` is 3, and the fields are 4 uint8_t in a KBDState structure.
We registered this with: We registered this with:
.. code:: c
vmstate_register(NULL, 0, &vmstate_kbd, s); vmstate_register(NULL, 0, &vmstate_kbd, s);
Note: talk about how vmstate <-> qdev interact, and what the instance ids mean. Note: talk about how vmstate <-> qdev interact, and what the instance ids mean.
You can search for VMSTATE_* macros for lots of types used in QEMU in You can search for ``VMSTATE_*`` macros for lots of types used in QEMU in
include/hw/hw.h. include/hw/hw.h.
=== More about versions === More about versions
-------------------
Version numbers are intended for major incompatible changes to the Version numbers are intended for major incompatible changes to the
migration of a device, and using them breaks backwards-migration migration of a device, and using them breaks backwards-migration
@ -168,22 +152,23 @@ compatibility; in general most changes can be made by adding Subsections
You can see that there are several version fields: You can see that there are several version fields:
- version_id: the maximum version_id supported by VMState for that device. - `version_id`: the maximum version_id supported by VMState for that device.
- minimum_version_id: the minimum version_id that VMState is able to understand - `minimum_version_id`: the minimum version_id that VMState is able to understand
for that device. for that device.
- minimum_version_id_old: For devices that were not able to port to vmstate, we can - `minimum_version_id_old`: For devices that were not able to port to vmstate, we can
assign a function that knows how to read this old state. This field is assign a function that knows how to read this old state. This field is
ignored if there is no load_state_old handler. ignored if there is no `load_state_old` handler.
So, VMState is able to read versions from minimum_version_id to So, VMState is able to read versions from minimum_version_id to
version_id. And the function load_state_old() (if present) is able to version_id. And the function ``load_state_old()`` (if present) is able to
load state from minimum_version_id_old to minimum_version_id. This load state from minimum_version_id_old to minimum_version_id. This
function is deprecated and will be removed when no more users are left. function is deprecated and will be removed when no more users are left.
Saving state will always create a section with the 'version_id' value Saving state will always create a section with the 'version_id' value
and thus can't be loaded by any older QEMU. and thus can't be loaded by any older QEMU.
=== Massaging functions === Massaging functions
-------------------
Sometimes, it is not enough to be able to save the state directly Sometimes, it is not enough to be able to save the state directly
from one structure, we need to fill the correct values there. One from one structure, we need to fill the correct values there. One
@ -194,24 +179,24 @@ load the state for the cpu that we have just loaded from the QEMUFile.
The functions to do that are inside a vmstate definition, and are called: The functions to do that are inside a vmstate definition, and are called:
- int (*pre_load)(void *opaque); - ``int (*pre_load)(void *opaque);``
This function is called before we load the state of one device. This function is called before we load the state of one device.
- int (*post_load)(void *opaque, int version_id); - ``int (*post_load)(void *opaque, int version_id);``
This function is called after we load the state of one device. This function is called after we load the state of one device.
- int (*pre_save)(void *opaque); - ``int (*pre_save)(void *opaque);``
This function is called before we save the state of one device. This function is called before we save the state of one device.
Example: You can look at hpet.c, that uses the three function to Example: You can look at hpet.c, that uses the three function to
massage the state that is transferred. massage the state that is transferred.
If you use memory API functions that update memory layout outside If you use memory API functions that update memory layout outside
initialization (i.e., in response to a guest action), this is a strong initialization (i.e., in response to a guest action), this is a strong
indication that you need to call these functions in a post_load callback. indication that you need to call these functions in a `post_load` callback.
Examples of such memory API functions are: Examples of such memory API functions are:
- memory_region_add_subregion() - memory_region_add_subregion()
@ -221,7 +206,8 @@ Examples of such memory API functions are:
- memory_region_set_address() - memory_region_set_address()
- memory_region_set_alias_offset() - memory_region_set_alias_offset()
=== Subsections === Subsections
-----------
The use of version_id allows to be able to migrate from older versions The use of version_id allows to be able to migrate from older versions
to newer versions of a device. But not the other way around. This to newer versions of a device. But not the other way around. This
@ -251,15 +237,17 @@ value that it uses.
Example: Example:
static bool ide_drive_pio_state_needed(void *opaque) .. code:: c
{
static bool ide_drive_pio_state_needed(void *opaque)
{
IDEState *s = opaque; IDEState *s = opaque;
return ((s->status & DRQ_STAT) != 0) return ((s->status & DRQ_STAT) != 0)
|| (s->bus->error_status & BM_STATUS_PIO_RETRY); || (s->bus->error_status & BM_STATUS_PIO_RETRY);
} }
const VMStateDescription vmstate_ide_drive_pio_state = { const VMStateDescription vmstate_ide_drive_pio_state = {
.name = "ide_drive/pio_state", .name = "ide_drive/pio_state",
.version_id = 1, .version_id = 1,
.minimum_version_id = 1, .minimum_version_id = 1,
@ -277,9 +265,9 @@ const VMStateDescription vmstate_ide_drive_pio_state = {
VMSTATE_INT32(packet_transfer_size, IDEState), VMSTATE_INT32(packet_transfer_size, IDEState),
VMSTATE_END_OF_LIST() VMSTATE_END_OF_LIST()
} }
}; };
const VMStateDescription vmstate_ide_drive = { const VMStateDescription vmstate_ide_drive = {
.name = "ide_drive", .name = "ide_drive",
.version_id = 3, .version_id = 3,
.minimum_version_id = 0, .minimum_version_id = 0,
@ -292,11 +280,11 @@ const VMStateDescription vmstate_ide_drive = {
&vmstate_ide_drive_pio_state, &vmstate_ide_drive_pio_state,
NULL NULL
} }
}; };
Here we have a subsection for the pio state. We only need to Here we have a subsection for the pio state. We only need to
save/send this state when we are in the middle of a pio operation save/send this state when we are in the middle of a pio operation
(that is what ide_drive_pio_state_needed() checks). If DRQ_STAT is (that is what ``ide_drive_pio_state_needed()`` checks). If DRQ_STAT is
not enabled, the values on that fields are garbage and don't need to not enabled, the values on that fields are garbage and don't need to
be sent. be sent.
@ -304,11 +292,12 @@ Using a condition function that checks a 'property' to determine whether
to send a subsection allows backwards migration compatibility when to send a subsection allows backwards migration compatibility when
new subsections are added. new subsections are added.
For example; For example:
a) Add a new property using DEFINE_PROP_BOOL - e.g. support-foo and
a) Add a new property using ``DEFINE_PROP_BOOL`` - e.g. support-foo and
default it to true. default it to true.
b) Add an entry to the HW_COMPAT_ for the previous version b) Add an entry to the ``HW_COMPAT_`` for the previous version that sets
that sets the property to false. the property to false.
c) Add a static bool support_foo function that tests the property. c) Add a static bool support_foo function that tests the property.
d) Add a subsection with a .needed set to the support_foo function d) Add a subsection with a .needed set to the support_foo function
e) (potentially) Add a pre_load that sets up a default value for 'foo' e) (potentially) Add a pre_load that sets up a default value for 'foo'
@ -332,25 +321,30 @@ in most cases. In general the preference is to tie the subsection to
the machine type, and allow reliable migrations, unless the behaviour the machine type, and allow reliable migrations, unless the behaviour
from omission of the subsection is really bad. from omission of the subsection is really bad.
= Not sending existing elements = Not sending existing elements
-----------------------------
Sometimes members of the VMState are no longer needed; Sometimes members of the VMState are no longer needed:
removing them will break migration compatibility
making them version dependent and bumping the version will break backwards - removing them will break migration compatibility
migration compatibility.
- making them version dependent and bumping the version will break backwards migration compatibility.
The best way is to: The best way is to:
a) Add a new property/compatibility/function in the same way for subsections
above. a) Add a new property/compatibility/function in the same way for subsections above.
b) replace the VMSTATE macro with the _TEST version of the macro, e.g.: b) replace the VMSTATE macro with the _TEST version of the macro, e.g.:
VMSTATE_UINT32(foo, barstruct)
``VMSTATE_UINT32(foo, barstruct)``
becomes becomes
VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz)
Sometime in the future when we no longer care about the ancient ``VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz)``
versions these can be killed off.
= Return path = Sometime in the future when we no longer care about the ancient versions these can be killed off.
Return path
-----------
In most migration scenarios there is only a single data path that runs In most migration scenarios there is only a single data path that runs
from the source VM to the destination, typically along a single fd (although from the source VM to the destination, typically along a single fd (although
@ -360,19 +354,23 @@ However, some uses need two way communication; in particular the Postcopy
destination needs to be able to request pages on demand from the source. destination needs to be able to request pages on demand from the source.
For these scenarios there is a 'return path' from the destination to the source; For these scenarios there is a 'return path' from the destination to the source;
qemu_file_get_return_path(QEMUFile* fwdpath) gives the QEMUFile* for the return ``qemu_file_get_return_path(QEMUFile* fwdpath)`` gives the QEMUFile* for the return
path. path.
Source side Source side
Forward path - written by migration thread Forward path - written by migration thread
Return path - opened by main thread, read by return-path thread Return path - opened by main thread, read by return-path thread
Destination side Destination side
Forward path - read by main thread Forward path - read by main thread
Return path - opened by main thread, written by main thread AND postcopy Return path - opened by main thread, written by main thread AND postcopy
thread (protected by rp_mutex) thread (protected by rp_mutex)
= Postcopy = Postcopy
========
'Postcopy' migration is a way to deal with migrations that refuse to converge 'Postcopy' migration is a way to deal with migrations that refuse to converge
(or take too long to converge) its plus side is that there is an upper bound on (or take too long to converge) its plus side is that there is an upper bound on
the amount of migration traffic and time it takes, the down side is that during the amount of migration traffic and time it takes, the down side is that during
@ -386,27 +384,30 @@ a fault that's translated by QEMU into a request to the source QEMU.
Postcopy can be combined with precopy (i.e. normal migration) so that if precopy Postcopy can be combined with precopy (i.e. normal migration) so that if precopy
doesn't finish in a given time the switch is made to postcopy. doesn't finish in a given time the switch is made to postcopy.
=== Enabling postcopy === Enabling postcopy
-----------------
To enable postcopy, issue this command on the monitor prior to the To enable postcopy, issue this command on the monitor prior to the
start of migration: start of migration:
migrate_set_capability postcopy-ram on ``migrate_set_capability postcopy-ram on``
The normal commands are then used to start a migration, which is still The normal commands are then used to start a migration, which is still
started in precopy mode. Issuing: started in precopy mode. Issuing:
migrate_start_postcopy ``migrate_start_postcopy``
will now cause the transition from precopy to postcopy. will now cause the transition from precopy to postcopy.
It can be issued immediately after migration is started or any It can be issued immediately after migration is started or any
time later on. Issuing it after the end of a migration is harmless. time later on. Issuing it after the end of a migration is harmless.
Note: During the postcopy phase, the bandwidth limits set using .. note::
migrate_set_speed is ignored (to avoid delaying requested pages that During the postcopy phase, the bandwidth limits set using
the destination is waiting for). ``migrate_set_speed`` is ignored (to avoid delaying requested pages that
the destination is waiting for).
=== Postcopy device transfer === Postcopy device transfer
------------------------
Loading of device data may cause the device emulation to access guest RAM Loading of device data may cause the device emulation to access guest RAM
that may trigger faults that have to be resolved by the source, as such that may trigger faults that have to be resolved by the source, as such
@ -416,6 +417,7 @@ before the device load begins to free the stream up. This is achieved by
'packaging' the device data into a blob that's read in one go. 'packaging' the device data into a blob that's read in one go.
Source behaviour Source behaviour
----------------
Until postcopy is entered the migration stream is identical to normal Until postcopy is entered the migration stream is identical to normal
precopy, except for the addition of a 'postcopy advise' command at precopy, except for the addition of a 'postcopy advise' command at
@ -423,13 +425,14 @@ the beginning, to tell the destination that postcopy might happen.
When postcopy starts the source sends the page discard data and then When postcopy starts the source sends the page discard data and then
forms the 'package' containing: forms the 'package' containing:
Command: 'postcopy listen' - Command: 'postcopy listen'
The device state - The device state
A series of sections, identical to the precopy streams device state stream A series of sections, identical to the precopy streams device state stream
containing everything except postcopiable devices (i.e. RAM) containing everything except postcopiable devices (i.e. RAM)
Command: 'postcopy run' - Command: 'postcopy run'
The 'package' is sent as the data part of a Command: 'CMD_PACKAGED', and the The 'package' is sent as the data part of a Command: ``CMD_PACKAGED``, and the
contents are formatted in the same way as the main migration stream. contents are formatted in the same way as the main migration stream.
During postcopy the source scans the list of dirty pages and sends them During postcopy the source scans the list of dirty pages and sends them
@ -441,49 +444,58 @@ to be sent quickly in the hope that those pages are likely to be used
by the destination soon. by the destination soon.
Destination behaviour Destination behaviour
---------------------
Initially the destination looks the same as precopy, with a single thread Initially the destination looks the same as precopy, with a single thread
reading the migration stream; the 'postcopy advise' and 'discard' commands reading the migration stream; the 'postcopy advise' and 'discard' commands
are processed to change the way RAM is managed, but don't affect the stream are processed to change the way RAM is managed, but don't affect the stream
processing. processing.
------------------------------------------------------------------------------ ::
------------------------------------------------------------------------------
1 2 3 4 5 6 7 1 2 3 4 5 6 7
main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN ) main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN )
thread | | thread | |
| (page request) | (page request)
| \___ | \___
v \ v \
listen thread: --- page -- page -- page -- page -- page -- listen thread: --- page -- page -- page -- page -- page --
a b c a b c
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
On receipt of CMD_PACKAGED (1) - On receipt of ``CMD_PACKAGED`` (1)
All the data associated with the package - the ( ... ) section in the
diagram - is read into memory, and the main thread recurses into
qemu_loadvm_state_main to process the contents of the package (2)
which contains commands (3,6) and devices (4...)
On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package) All the data associated with the package - the ( ... ) section in the diagram -
a new thread (a) is started that takes over servicing the migration stream, is read into memory, and the main thread recurses into qemu_loadvm_state_main
while the main thread carries on loading the package. It loads normal to process the contents of the package (2) which contains commands (3,6) and
background page data (b) but if during a device load a fault happens (5) the devices (4...)
returned page (c) is loaded by the listen thread allowing the main threads
device load to carry on.
The last thing in the CMD_PACKAGED is a 'RUN' command (6) letting the destination - On receipt of 'postcopy listen' - 3 -(i.e. the 1st command in the package)
CPUs start running.
At the end of the CMD_PACKAGED (7) the main thread returns to normal running behaviour
and is no longer used by migration, while the listen thread carries
on servicing page data until the end of migration.
=== Postcopy states === a new thread (a) is started that takes over servicing the migration stream,
while the main thread carries on loading the package. It loads normal
background page data (b) but if during a device load a fault happens (5)
the returned page (c) is loaded by the listen thread allowing the main
threads device load to carry on.
- The last thing in the ``CMD_PACKAGED`` is a 'RUN' command (6)
letting the destination CPUs start running. At the end of the
``CMD_PACKAGED`` (7) the main thread returns to normal running behaviour and
is no longer used by migration, while the listen thread carries on servicing
page data until the end of migration.
Postcopy states
---------------
Postcopy moves through a series of states (see postcopy_state) from Postcopy moves through a series of states (see postcopy_state) from
ADVISE->DISCARD->LISTEN->RUNNING->END ADVISE->DISCARD->LISTEN->RUNNING->END
Advise: Set at the start of migration if postcopy is enabled, even - Advise
Set at the start of migration if postcopy is enabled, even
if it hasn't had the start command; here the destination if it hasn't had the start command; here the destination
checks that its OS has the support needed for postcopy, and performs checks that its OS has the support needed for postcopy, and performs
setup to ensure the RAM mappings are suitable for later postcopy. setup to ensure the RAM mappings are suitable for later postcopy.
@ -491,13 +503,17 @@ ADVISE->DISCARD->LISTEN->RUNNING->END
required OS support is not present. required OS support is not present.
(Triggered by reception of POSTCOPY_ADVISE command) (Triggered by reception of POSTCOPY_ADVISE command)
Discard: Entered on receipt of the first 'discard' command; prior to - Discard
Entered on receipt of the first 'discard' command; prior to
the first Discard being performed, hugepages are switched off the first Discard being performed, hugepages are switched off
(using madvise) to ensure that no new huge pages are created (using madvise) to ensure that no new huge pages are created
during the postcopy phase, and to cause any huge pages that during the postcopy phase, and to cause any huge pages that
have discards on them to be broken. have discards on them to be broken.
Listen: The first command in the package, POSTCOPY_LISTEN, switches - Listen
The first command in the package, POSTCOPY_LISTEN, switches
the destination state to Listen, and starts a new thread the destination state to Listen, and starts a new thread
(the 'listen thread') which takes over the job of receiving (the 'listen thread') which takes over the job of receiving
pages off the migration stream, while the main thread carries pages off the migration stream, while the main thread carries
@ -506,17 +522,22 @@ ADVISE->DISCARD->LISTEN->RUNNING->END
any access to missing pages (on Linux using the 'userfault' any access to missing pages (on Linux using the 'userfault'
system). system).
Running: POSTCOPY_RUN causes the destination to synchronise all - Running
POSTCOPY_RUN causes the destination to synchronise all
state and start the CPUs and IO devices running. The main state and start the CPUs and IO devices running. The main
thread now finishes processing the migration package and thread now finishes processing the migration package and
now carries on as it would for normal precopy migration now carries on as it would for normal precopy migration
(although it can't do the cleanup it would do as it (although it can't do the cleanup it would do as it
finishes a normal migration). finishes a normal migration).
End: The listen thread can now quit, and perform the cleanup of migration - End
The listen thread can now quit, and perform the cleanup of migration
state, the migration is now complete. state, the migration is now complete.
=== Source side page maps === Source side page maps
---------------------
The source side keeps two bitmaps during postcopy; 'the migration bitmap' The source side keeps two bitmaps during postcopy; 'the migration bitmap'
and 'unsent map'. The 'migration bitmap' is basically the same as in and 'unsent map'. The 'migration bitmap' is basically the same as in
@ -529,6 +550,7 @@ The 'unsent map' is used for the transition to postcopy. It is a bitmap that
has a bit cleared whenever a page is sent to the destination, however during has a bit cleared whenever a page is sent to the destination, however during
the transition to postcopy mode it is combined with the migration bitmap the transition to postcopy mode it is combined with the migration bitmap
to form a set of pages that: to form a set of pages that:
a) Have been sent but then redirtied (which must be discarded) a) Have been sent but then redirtied (which must be discarded)
b) Have not yet been sent - which also must be discarded to cause any b) Have not yet been sent - which also must be discarded to cause any
transparent huge pages built during precopy to be broken. transparent huge pages built during precopy to be broken.
@ -540,15 +562,17 @@ request for a page that has already been sent is ignored. Duplicate requests
such as this can happen as a page is sent at about the same time the such as this can happen as a page is sent at about the same time the
destination accesses it. destination accesses it.
=== Postcopy with hugepages === Postcopy with hugepages
-----------------------
Postcopy now works with hugetlbfs backed memory: Postcopy now works with hugetlbfs backed memory:
a) The linux kernel on the destination must support userfault on hugepages. a) The linux kernel on the destination must support userfault on hugepages.
b) The huge-page configuration on the source and destination VMs must be b) The huge-page configuration on the source and destination VMs must be
identical; i.e. RAMBlocks on both sides must use the same page size. identical; i.e. RAMBlocks on both sides must use the same page size.
c) Note that -mem-path /dev/hugepages will fall back to allocating normal c) Note that ``-mem-path /dev/hugepages`` will fall back to allocating normal
RAM if it doesn't have enough hugepages, triggering (b) to fail. RAM if it doesn't have enough hugepages, triggering (b) to fail.
Using -mem-prealloc enforces the allocation using hugepages. Using ``-mem-prealloc`` enforces the allocation using hugepages.
d) Care should be taken with the size of hugepage used; postcopy with 2MB d) Care should be taken with the size of hugepage used; postcopy with 2MB
hugepages works well, however 1GB hugepages are likely to be problematic hugepages works well, however 1GB hugepages are likely to be problematic
since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps link, since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps link,