diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/devel/build-system.txt | 13 | ||||
| -rw-r--r-- | docs/devel/migration.rst (renamed from docs/devel/migration.txt) | 476 | ||||
| -rw-r--r-- | docs/interop/prl-xml.txt | 158 | ||||
| -rw-r--r-- | docs/interop/vhost-user.txt | 96 | ||||
| -rw-r--r-- | docs/nvdimm.txt | 31 |
5 files changed, 541 insertions, 233 deletions
diff --git a/docs/devel/build-system.txt b/docs/devel/build-system.txt index 386ef36ee3..52501f2ad9 100644 --- a/docs/devel/build-system.txt +++ b/docs/devel/build-system.txt @@ -510,3 +510,16 @@ default-configs/$TARGET-NAME file as input. This is the entrypoint used when make recurses to build a single system or userspace emulator target. It is merely a symlink back to the Makefile.target in the top level. + + +Useful make targets +=================== + +- help + + Print a help message for the most common build targets. + +- print-VAR + + Print the value of the variable VAR. Useful for debugging the build + system. diff --git a/docs/devel/migration.txt b/docs/devel/migration.rst index 4030703726..bf97080dac 100644 --- a/docs/devel/migration.txt +++ b/docs/devel/migration.rst @@ -1,4 +1,6 @@ -= Migration = +========= +Migration +========= 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 @@ -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 (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 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 savevm/loadvm functionality. -=== State Live Migration === +State Live Migration +==================== This is used for RAM and block devices. It is not yet ported to vmstate. <Fill more information here> -=== What is the common infrastructure === +Common infrastructure +===================== -QEMU uses a QEMUFile abstraction to be able to do migration. Any type -of migration that wants to use QEMU infrastructure has to create a -QEMUFile with: +The files, sockets or fd's that carry the migration stream are abstracted by +the ``QEMUFile`` type (see `migration/qemu-file.h`). In most cases this +is connected to a subtype of ``QIOChannel`` (see `io/`). -QEMUFile *qemu_fopen_ops(void *opaque, - 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 === +Saving the state of one device +============================== The state of a device is saved using intermediate buffers. There are some helper functions to assist this saving. @@ -93,34 +68,38 @@ 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 change the state to store more/different information. We use the 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 -the state as the newer version. But load_state sometimes is able to +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 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. Each device has to register two functions, one to save the state and another to load the state back. -int register_savevm(DeviceState *dev, - const char *idstr, - int instance_id, - int version_id, - SaveStateHandler *save_state, - LoadStateHandler *load_state, - void *opaque); +.. code:: c + + int register_savevm(DeviceState *dev, + const char *idstr, + int instance_id, + int version_id, + SaveStateHandler *save_state, + LoadStateHandler *load_state, + void *opaque); -typedef void SaveStateHandler(QEMUFile *f, void *opaque); -typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id); + typedef void SaveStateHandler(QEMUFile *f, void *opaque); + typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id); -The important functions for the device state format are the save_state -and load_state. Notice that load_state receives a version_id -parameter to know what state format is receiving. save_state doesn't +The important functions for the device state format are the `save_state` +and `load_state`. Notice that `load_state` receives a version_id +parameter to know what state format is receiving. `save_state` doesn't 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 that we have to maintain two functions in sync. If we did one change @@ -135,31 +114,36 @@ save/load functions. An example (from hw/input/pckbd.c) -static const VMStateDescription vmstate_kbd = { - .name = "pckbd", - .version_id = 3, - .minimum_version_id = 3, - .fields = (VMStateField[]) { - VMSTATE_UINT8(write_cmd, KBDState), - VMSTATE_UINT8(status, KBDState), - VMSTATE_UINT8(mode, KBDState), - VMSTATE_UINT8(pending, KBDState), - VMSTATE_END_OF_LIST() - } -}; +.. code:: c + + static const VMStateDescription vmstate_kbd = { + .name = "pckbd", + .version_id = 3, + .minimum_version_id = 3, + .fields = (VMStateField[]) { + VMSTATE_UINT8(write_cmd, KBDState), + VMSTATE_UINT8(status, KBDState), + VMSTATE_UINT8(mode, KBDState), + VMSTATE_UINT8(pending, KBDState), + VMSTATE_END_OF_LIST() + } + }; 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: +.. code:: c + vmstate_register(NULL, 0, &vmstate_kbd, s); 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. -=== More about versions === +More about versions +------------------- Version numbers are intended for major incompatible changes to the 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: -- 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 +- `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 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 - 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 -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 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 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 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: -- int (*pre_load)(void *opaque); +- ``int (*pre_load)(void *opaque);`` 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. -- int (*pre_save)(void *opaque); +- ``int (*pre_save)(void *opaque);`` 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 - massage the state that is transferred. +massage the state that is transferred. If you use memory API functions that update memory layout outside 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: - memory_region_add_subregion() @@ -221,7 +206,8 @@ Examples of such memory API functions are: - memory_region_set_address() - memory_region_set_alias_offset() -=== Subsections === +Subsections +----------- 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 @@ -251,52 +237,54 @@ value that it uses. Example: -static bool ide_drive_pio_state_needed(void *opaque) -{ - IDEState *s = opaque; - - return ((s->status & DRQ_STAT) != 0) - || (s->bus->error_status & BM_STATUS_PIO_RETRY); -} - -const VMStateDescription vmstate_ide_drive_pio_state = { - .name = "ide_drive/pio_state", - .version_id = 1, - .minimum_version_id = 1, - .pre_save = ide_drive_pio_pre_save, - .post_load = ide_drive_pio_post_load, - .needed = ide_drive_pio_state_needed, - .fields = (VMStateField[]) { - VMSTATE_INT32(req_nb_sectors, IDEState), - VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1, - vmstate_info_uint8, uint8_t), - VMSTATE_INT32(cur_io_buffer_offset, IDEState), - VMSTATE_INT32(cur_io_buffer_len, IDEState), - VMSTATE_UINT8(end_transfer_fn_idx, IDEState), - VMSTATE_INT32(elementary_transfer_size, IDEState), - VMSTATE_INT32(packet_transfer_size, IDEState), - VMSTATE_END_OF_LIST() - } -}; - -const VMStateDescription vmstate_ide_drive = { - .name = "ide_drive", - .version_id = 3, - .minimum_version_id = 0, - .post_load = ide_drive_post_load, - .fields = (VMStateField[]) { - .... several fields .... - VMSTATE_END_OF_LIST() - }, - .subsections = (const VMStateDescription*[]) { - &vmstate_ide_drive_pio_state, - NULL - } -}; +.. code:: c + + static bool ide_drive_pio_state_needed(void *opaque) + { + IDEState *s = opaque; + + return ((s->status & DRQ_STAT) != 0) + || (s->bus->error_status & BM_STATUS_PIO_RETRY); + } + + const VMStateDescription vmstate_ide_drive_pio_state = { + .name = "ide_drive/pio_state", + .version_id = 1, + .minimum_version_id = 1, + .pre_save = ide_drive_pio_pre_save, + .post_load = ide_drive_pio_post_load, + .needed = ide_drive_pio_state_needed, + .fields = (VMStateField[]) { + VMSTATE_INT32(req_nb_sectors, IDEState), + VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1, + vmstate_info_uint8, uint8_t), + VMSTATE_INT32(cur_io_buffer_offset, IDEState), + VMSTATE_INT32(cur_io_buffer_len, IDEState), + VMSTATE_UINT8(end_transfer_fn_idx, IDEState), + VMSTATE_INT32(elementary_transfer_size, IDEState), + VMSTATE_INT32(packet_transfer_size, IDEState), + VMSTATE_END_OF_LIST() + } + }; + + const VMStateDescription vmstate_ide_drive = { + .name = "ide_drive", + .version_id = 3, + .minimum_version_id = 0, + .post_load = ide_drive_post_load, + .fields = (VMStateField[]) { + .... several fields .... + VMSTATE_END_OF_LIST() + }, + .subsections = (const VMStateDescription*[]) { + &vmstate_ide_drive_pio_state, + NULL + } + }; 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 -(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 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 new subsections are added. -For example; - a) Add a new property using DEFINE_PROP_BOOL - e.g. support-foo and +For example: + + a) Add a new property using ``DEFINE_PROP_BOOL`` - e.g. support-foo and default it to true. - b) Add an entry to the HW_COMPAT_ for the previous version - that sets the property to false. + b) Add an entry to the ``HW_COMPAT_`` for the previous version that sets + the property to false. 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 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 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 - migration compatibility. + - removing them will break migration compatibility + + - making them version dependent and bumping the version will break backwards migration compatibility. 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.: - VMSTATE_UINT32(foo, barstruct) + + ``VMSTATE_UINT32(foo, barstruct)`` + becomes - VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz) - Sometime in the future when we no longer care about the ancient -versions these can be killed off. + ``VMSTATE_UINT32_TEST(foo, barstruct, pre_version_baz)`` + + Sometime in the future when we no longer care about the ancient versions these can be killed off. -= Return path = +Return path +----------- 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 @@ -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. 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. Source side + Forward path - written by migration thread Return path - opened by main thread, read by return-path thread Destination side + Forward path - read by main thread 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 (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 @@ -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 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 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 started in precopy mode. Issuing: -migrate_start_postcopy +``migrate_start_postcopy`` will now cause the transition from precopy to postcopy. It can be issued immediately after migration is started or any time later on. Issuing it after the end of a migration is harmless. -Note: During the postcopy phase, the bandwidth limits set using -migrate_set_speed is ignored (to avoid delaying requested pages that -the destination is waiting for). +.. note:: + During the postcopy phase, the bandwidth limits set using + ``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 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. Source behaviour +---------------- Until postcopy is entered the migration stream is identical to normal 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 forms the 'package' containing: - Command: 'postcopy listen' - The device state - A series of sections, identical to the precopy streams device state stream - containing everything except postcopiable devices (i.e. RAM) - Command: 'postcopy run' + - Command: 'postcopy listen' + - The device state -The 'package' is sent as the data part of a Command: 'CMD_PACKAGED', and the + A series of sections, identical to the precopy streams device state stream + containing everything except postcopiable devices (i.e. RAM) + - Command: 'postcopy run' + +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. During postcopy the source scans the list of dirty pages and sends them @@ -441,82 +444,100 @@ to be sent quickly in the hope that those pages are likely to be used by the destination soon. Destination behaviour +--------------------- Initially the destination looks the same as precopy, with a single thread 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 processing. ------------------------------------------------------------------------------- - 1 2 3 4 5 6 7 -main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN ) -thread | | - | (page request) - | \___ - v \ -listen thread: --- page -- page -- page -- page -- page -- - - a b c ------------------------------------------------------------------------------- - -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) -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 === +:: + + ------------------------------------------------------------------------------ + 1 2 3 4 5 6 7 + main -----DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN ) + thread | | + | (page request) + | \___ + v \ + listen thread: --- page -- page -- page -- page -- page -- + + a b c + ------------------------------------------------------------------------------ + +- 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) + + 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 ADVISE->DISCARD->LISTEN->RUNNING->END - Advise: Set at the start of migration if postcopy is enabled, even - if it hasn't had the start command; here the destination - checks that its OS has the support needed for postcopy, and performs - setup to ensure the RAM mappings are suitable for later postcopy. - The destination will fail early in migration at this point if the - required OS support is not present. - (Triggered by reception of POSTCOPY_ADVISE command) - - Discard: Entered on receipt of the first 'discard' command; prior to - the first Discard being performed, hugepages are switched off - (using madvise) to ensure that no new huge pages are created - during the postcopy phase, and to cause any huge pages that - have discards on them to be broken. - - Listen: The first command in the package, POSTCOPY_LISTEN, switches - the destination state to Listen, and starts a new thread - (the 'listen thread') which takes over the job of receiving - pages off the migration stream, while the main thread carries - on processing the blob. With this thread able to process page - reception, the destination now 'sensitises' the RAM to detect - any access to missing pages (on Linux using the 'userfault' - system). - - Running: POSTCOPY_RUN causes the destination to synchronise all - state and start the CPUs and IO devices running. The main - thread now finishes processing the migration package and - now carries on as it would for normal precopy migration - (although it can't do the cleanup it would do as it - finishes a normal migration). - - End: The listen thread can now quit, and perform the cleanup of migration - state, the migration is now complete. - -=== Source side page maps === + - Advise + + Set at the start of migration if postcopy is enabled, even + if it hasn't had the start command; here the destination + checks that its OS has the support needed for postcopy, and performs + setup to ensure the RAM mappings are suitable for later postcopy. + The destination will fail early in migration at this point if the + required OS support is not present. + (Triggered by reception of POSTCOPY_ADVISE command) + + - Discard + + Entered on receipt of the first 'discard' command; prior to + the first Discard being performed, hugepages are switched off + (using madvise) to ensure that no new huge pages are created + during the postcopy phase, and to cause any huge pages that + have discards on them to be broken. + + - Listen + + The first command in the package, POSTCOPY_LISTEN, switches + the destination state to Listen, and starts a new thread + (the 'listen thread') which takes over the job of receiving + pages off the migration stream, while the main thread carries + on processing the blob. With this thread able to process page + reception, the destination now 'sensitises' the RAM to detect + any access to missing pages (on Linux using the 'userfault' + system). + + - Running + + POSTCOPY_RUN causes the destination to synchronise all + state and start the CPUs and IO devices running. The main + thread now finishes processing the migration package and + now carries on as it would for normal precopy migration + (although it can't do the cleanup it would do as it + finishes a normal migration). + + - End + + The listen thread can now quit, and perform the cleanup of migration + state, the migration is now complete. + +Source side page maps +--------------------- The source side keeps two bitmaps during postcopy; 'the migration bitmap' 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 the transition to postcopy mode it is combined with the migration bitmap to form a set of pages that: + 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 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 destination accesses it. -=== Postcopy with hugepages === +Postcopy with hugepages +----------------------- Postcopy now works with hugetlbfs backed memory: + 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 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. - 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 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, diff --git a/docs/interop/prl-xml.txt b/docs/interop/prl-xml.txt new file mode 100644 index 0000000000..7031f8752c --- /dev/null +++ b/docs/interop/prl-xml.txt @@ -0,0 +1,158 @@ += License = + +Copyright (c) 2015-2017, Virtuozzo, Inc. +Authors: + 2015 Denis Lunev <den@openvz.org> + 2015 Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> + 2016-2017 Klim Kireev <klim.kireev@virtuozzo.com> + 2016-2017 Edgar Kaziakhmedov <edgar.kaziakhmedov@virtuozzo.com> + +This work is licensed under the terms of the GNU GPL, version 2 or later. +See the COPYING file in the top-level directory. + +This specification contains minimal information about Parallels Disk Format, +which is enough to proper work with QEMU. Nevertheless, Parallels Cloud Server +and Parallels Desktop are able to add some unspecified nodes to xml and use +them, but they are for internal work and don't affect functionality. Also it +uses auxiliary xml "Snapshot.xml", which allows to store optional snapshot +information, but it doesn't influence open/read/write functionality. QEMU and +other software should not use fields not covered in this document and +Snapshot.xml file and must leave them as is. + += Parallels Disk Format = + +Parallels disk consists of two parts: the set of snapshots and the disk +descriptor file, which stores information about all files and snapshots. + +== Definitions == + Snapshot a record of the contents captured at a particular time, + capable of storing current state. A snapshot has UUID and + parent UUID. + + Snapshot image an overlay representing the difference between this + snapshot and some earlier snapshot. + + Overlay an image storing the different sectors between two captured + states. + + Root image snapshot image with no parent, the root of snapshot tree. + + Storage the backing storage for a subset of the virtual disk. When + there is more than one storage in a Parallels disk then that + is referred to as a split image. In this case every storage + covers specific address space area of the disk and has its + particular root image. Split images are not considered here + and are not supported. Each storage consists of disk + parameters and a list of images. The list of images always + contains a root image and may also contain overlays. The + root image can be an expandable Parallels image file or + plain. Overlays must be expandable. + + Description DiskDescriptor.xml stores information about disk parameters, + file snapshots, storages. + + Top The overlay between actual state and some previous snapshot. + Snapshot It is not a snapshot in the classical sense because it + serves as the active image that the guest writes to. + + Sector a 512-byte data chunk. + +== Description file == +All information is placed in a single XML element Parallels_disk_image. +The element has only one attribute "Version", that must be 1.0. +Schema of DiskDescriptor.xml: + +<Parallels_disk_image Version="1.0"> + <Disk_Parameters> + ... + </Disk_Parameters> + <StorageData> + ... + </StorageData> + <Snapshots> + ... + </Snapshots> +</Parallels_disk_image> + +== Disk_Parameters element == +The Disk_Parameters element describes the physical layout of the virtual disk +and some general settings. + +The Disk_Parameters element MUST contain the following child elements: + * Disk_size - number of sectors in the disk, + desired size of the disk. + * Cylinders - number of the disk cylinders. + * Heads - number of the disk heads. + * Sectors - number of the disk sectors per cylinder + (sector size is 512 bytes) + Limitation: Product of the Heads, Sectors and Cylinders + values MUST be equal to the value of the Disk_size parameter. + * Padding - must be 0. Parallels Cloud Server and Parallels Desktop may + use padding set to 1, however this case is not covered + by this spec, QEMU and other software should not open + such disks and should not create them. + +== StorageData element == +This element of the file describes the root image and all snapshot images. + +The StorageData element consists of the Storage child element, as shown below: +<StorageData> + <Storage> + ... + </Storage> +</StorageData> + +A Storage element has following child elements: + * Start - start sector of the storage, in case of non split storage + equals to 0. + * End - number of sector following the last sector, in case of non + split storage equals to Disk_size. + * Blocksize - storage cluster size, number of sectors per one cluster. + Cluster size for each "Compressed" (see below) image in + parallels disk must be equal to this field. Note: cluster + size for Parallels Expandable Image is in 'tracks' field of + its header (see docs/interop/parallels.txt). + * Several Image child elements. + +Each Image element has following child elements: + * GUID - image identifier, UUID in curly brackets. + For instance, {12345678-9abc-def1-2345-6789abcdef12}. + The GUID is used by the Snapshots element to reference images + (see below) + * Type - image type of the element. It can be: + "Plain" for raw files. + "Compressed" for expanding disks. + * File - path to image file. Path can be relative to DiskDecriptor.xml or + absolute. + +== Snapshots element == +The Snapshots element describes the snapshot relations with the snapshot tree. + +The element contains the set of Shot child elements, as shown below: +<Snapshots> + <TopGUID> ... </TopGUID> /* Optional child element */ + <Shot> + ... + </Shot> + <Shot> + ... + </Shot> + ... +</Snapshots> + +Each Shot element contains the following child elements: + * GUID - an image GUID. + * ParentGUID - GUID of the image of the parent snapshot. + +The software may traverse snapshots from child to parent using <ParentGUID> +field as reference. ParentGUID of root snapshot is +{00000000-0000-0000-0000-000000000000}. There should be only one root +snapshot. Top snapshot could be described via two ways: via TopGUID child +element of the Snapshots element or via predefined GUID +{5fbaabe3-6958-40ff-92a7-860e329aab41}. If TopGUID is defined, predefined GUID is +interpreted as usual GUID. All snapshot images (except Top Snapshot) should be +opened read-only. There is another predefined GUID, +BackupID = {704718e1-2314-44c8-9087-d78ed36b0f4e}, which is used by original and +some third-party software for backup, QEMU and other software may operate with +images with GUID = BackupID as usual, however, it is not recommended to use this +GUID for new disks. Top snapshot cannot have this GUID. diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt index 954771d0d8..9fcf48d611 100644 --- a/docs/interop/vhost-user.txt +++ b/docs/interop/vhost-user.txt @@ -53,8 +53,8 @@ Depending on the request type, payload can be: * A vring state description --------------- - | index | num | - --------------- + | index | num | + --------------- Index: a 32-bit index Num: a 32-bit number @@ -66,11 +66,14 @@ Depending on the request type, payload can be: Index: a 32-bit vring index Flags: a 32-bit vring flags - Descriptor: a 64-bit user address of the vring descriptor table - Used: a 64-bit user address of the vring used ring - Available: a 64-bit user address of the vring available ring + Descriptor: a 64-bit ring address of the vring descriptor table + Used: a 64-bit ring address of the vring used ring + Available: a 64-bit ring address of the vring available ring Log: a 64-bit guest address for logging + Note that a ring address is an IOVA if VIRTIO_F_IOMMU_PLATFORM has been + negotiated. Otherwise it is a user address. + * Memory regions description --------------------------------------------------- | num regions | padding | region0 | ... | region7 | @@ -116,6 +119,19 @@ Depending on the request type, payload can be: - 3: IOTLB invalidate - 4: IOTLB access fail + * Virtio device config space + ----------------------------------- + | offset | size | flags | payload | + ----------------------------------- + + Offset: a 32-bit offset of virtio device's configuration space + Size: a 32-bit configuration space access size in bytes + Flags: a 32-bit value: + - 0: Vhost master messages used for writeable fields + - 1: Vhost master messages used for live migration + Payload: Size bytes array holding the contents of the virtio + device's configuration space + In QEMU the vhost-user message is implemented with the following struct: typedef struct VhostUserMsg { @@ -129,6 +145,7 @@ typedef struct VhostUserMsg { VhostUserMemory memory; VhostUserLog log; struct vhost_iotlb_msg iotlb; + VhostUserConfig config; }; } QEMU_PACKED VhostUserMsg; @@ -211,8 +228,8 @@ Multiple queue is treated as a protocol extension, hence the slave has to implement protocol features first. The multiple queues feature is supported only when the protocol feature VHOST_USER_PROTOCOL_F_MQ (bit 0) is set. -The max number of queues the slave supports can be queried with message -VHOST_USER_GET_PROTOCOL_FEATURES. Master should stop when the number of +The max number of queue pairs the slave supports can be queried with message +VHOST_USER_GET_QUEUE_NUM. Master should stop when the number of requested queues is bigger than that. As all queues share one connection, the master uses a unique index for each @@ -273,6 +290,30 @@ Once the source has finished migration, rings will be stopped by the source. No further update must be done before rings are restarted. +Memory access +------------- + +The master sends a list of vhost memory regions to the slave using the +VHOST_USER_SET_MEM_TABLE message. Each region has two base addresses: a guest +address and a user address. + +Messages contain guest addresses and/or user addresses to reference locations +within the shared memory. The mapping of these addresses works as follows. + +User addresses map to the vhost memory region containing that user address. + +When the VIRTIO_F_IOMMU_PLATFORM feature has not been negotiated: + + * Guest addresses map to the vhost memory region containing that guest + address. + +When the VIRTIO_F_IOMMU_PLATFORM feature has been negotiated: + + * Guest addresses are also called I/O virtual addresses (IOVAs). They are + translated to user addresses via the IOTLB. + + * The vhost memory region guest address is not used. + IOMMU support ------------- @@ -596,6 +637,32 @@ Master message types and expect this message once (per VQ) during device configuration (ie. before the master starts the VQ). + * VHOST_USER_GET_CONFIG + + Id: 24 + Equivalent ioctl: N/A + Master payload: virtio device config space + Slave payload: virtio device config space + + Submitted by the vhost-user master to fetch the contents of the virtio + device configuration space, vhost-user slave's payload size MUST match + master's request, vhost-user slave uses zero length of payload to + indicate an error to vhost-user master. The vhost-user master may + cache the contents to avoid repeated VHOST_USER_GET_CONFIG calls. + +* VHOST_USER_SET_CONFIG + + Id: 25 + Equivalent ioctl: N/A + Master payload: virtio device config space + Slave payload: N/A + + Submitted by the vhost-user master when the Guest changes the virtio + device configuration space and also can be used for live migration + on the destination host. The vhost-user slave must check the flags + field, and slaves MUST NOT accept SET_CONFIG for read-only + configuration space fields unless the live migration bit is set. + Slave message types ------------------- @@ -614,6 +681,21 @@ Slave message types This request should be send only when VIRTIO_F_IOMMU_PLATFORM feature has been successfully negotiated. +* VHOST_USER_SLAVE_CONFIG_CHANGE_MSG + + Id: 2 + Equivalent ioctl: N/A + Slave payload: N/A + Master payload: N/A + + Vhost-user slave sends such messages to notify that the virtio device's + configuration space has changed, for those host devices which can support + such feature, host driver can send VHOST_USER_GET_CONFIG message to slave + to get the latest content. If VHOST_USER_PROTOCOL_F_REPLY_ACK is + negotiated, and slave set the VHOST_USER_NEED_REPLY flag, master must + respond with zero when operation is successfully completed, or non-zero + otherwise. + VHOST_USER_PROTOCOL_F_REPLY_ACK: ------------------------------- The original vhost-user specification only demands replies for certain diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt index 2d9f8c0e8c..e903d8bb09 100644 --- a/docs/nvdimm.txt +++ b/docs/nvdimm.txt @@ -122,3 +122,34 @@ Note: M >= size of RAM devices + size of statically plugged vNVDIMM devices + size of hotplugged vNVDIMM devices + +Alignment +--------- + +QEMU uses mmap(2) to maps vNVDIMM backends and aligns the mapping +address to the page size (getpagesize(2)) by default. However, some +types of backends may require an alignment different than the page +size. In that case, QEMU v2.12.0 and later provide 'align' option to +memory-backend-file to allow users to specify the proper alignment. + +For example, device dax require the 2 MB alignment, so we can use +following QEMU command line options to use it (/dev/dax0.0) as the +backend of vNVDIMM: + + -object memory-backend-file,id=mem1,share=on,mem-path=/dev/dax0.0,size=4G,align=2M + -device nvdimm,id=nvdimm1,memdev=mem1 + +Guest Data Persistence +---------------------- + +Though QEMU supports multiple types of vNVDIMM backends on Linux, +currently the only one that can guarantee the guest write persistence +is the device DAX on the real NVDIMM device (e.g., /dev/dax0.0), to +which all guest access do not involve any host-side kernel cache. + +When using other types of backends, it's suggested to set 'unarmed' +option of '-device nvdimm' to 'on', which sets the unarmed flag of the +guest NVDIMM region mapping structure. This unarmed flag indicates +guest software that this vNVDIMM device contains a region that cannot +accept persistent writes. In result, for example, the guest Linux +NVDIMM driver, marks such vNVDIMM device as read-only. |