| /openbmc/qemu/hw/vfio/ |
| H A D | migration.c | 109 VFIOMigration *migration = vbasedev->migration; in vfio_migration_send_event() local
124 dev->id, qom_path, mig_state_to_qapi_state(migration->device_state)); in vfio_migration_send_event()
130 VFIOMigration *migration = vbasedev->migration; in vfio_migration_set_device_state() local
135 migration->device_state = state; in vfio_migration_set_device_state()
144 VFIOMigration *migration = vbasedev->migration; in vfio_migration_set_state() local
159 if (new_state == migration->device_state) { in vfio_migration_set_state()
204 if (migration->data_fd != -1) { in vfio_migration_set_state()
215 migration->data_fd = mig_state->data_fd; in vfio_migration_set_state()
248 VFIOMigration *migration = vbasedev->migration; in vfio_load_buffer() local
251 ret = qemu_file_get_to_fd(f, migration->data_fd, data_size); in vfio_load_buffer()
[all …]
|
| /openbmc/openbmc/poky/documentation/migration-guides/ |
| H A D | index.rst | 14 migration-general
23 migration-3.3
24 migration-3.2
25 migration-3.1
26 migration-3.0
27 migration-2.7
28 migration-2.6
29 migration-2.5
30 migration-2.4
31 migration-2.3
[all …]
|
| H A D | release-notes-4.3.1.rst | 59 - migration-4.3: additional migration items
60 - migration-4.3: adjustments to existing text
61 - migration-4.3: remove some unnecessary items
62 - migration-guides: QEMU_USE_SLIRP variable removed
63 - migration-guides: add BitBake changes
64 - migration-guides: add debian 12 to newly supported distros
65 - migration-guides: add kernel notes
66 - migration-guides: add testing notes
67 - migration-guides: add utility notes
68 - migration-guides: edgerouter machine removed
[all …]
|
| H A D | migration-5.0.rst | 9 This section provides migration information for moving to the Yocto
13 the previous migration notes from your release to this new one:
15 - :doc:`/migration-guides/migration-4.3`
16 - :doc:`/migration-guides/migration-4.2`
17 - :doc:`/migration-guides/migration-4.1`
18 - :doc:`/migration-guides/migration-4.0`
19 - :doc:`/migration-guides/migration-3.4`
20 - :doc:`/migration-guides/migration-3.3`
21 - :doc:`/migration-guides/migration-3.2`
29 out the box, older kernels are not supported. See :ref:`4.3 migration notes
[all …]
|
| H A D | migration-general.rst | 81 the migration (e.g. added/removed packages, added/removed files, size
84 #. Enable :ref:`ref-classes-buildhistory` before the migration
86 #. Run a pre-migration build
97 migration, to make the commit from the pre-migration build easy to find
98 as you may end up running multiple builds during the migration.
100 #. Perform the migration
|
| /openbmc/qemu/qapi/ |
| H A D | migration.json | 15 # Detailed migration status.
22 # @total: total amount of bytes involved in the migration process
80 # Detailed XBZRLE migration cache statistics
106 # Detailed migration compression statistics
128 # An enumeration of migration status.
130 # @none: no migration has ever happened.
132 # @setup: migration process has been initiated.
134 # @cancelling: in the process of cancelling migration.
136 # @cancelled: cancelling migration is finished.
138 # @active: in the process of doing migration.
[all …]
|
| H A D | yank.json | 18 'data': [ 'block-node', 'chardev', 'migration' ] }
59 # - migration: Yanking it will shut down all migration connections.
60 # Unlike @migrate_cancel, it will not notify the migration process,
61 # so migration will go into @failed state, instead of @cancelled
|
| H A D | vfio.json | 12 # An enumeration of the VFIO device migration states.
42 # This event is emitted when a VFIO device migration state is changed.
48 # @device-state: The new changed device migration state.
|
| /openbmc/qemu/docs/devel/migration/ |
| H A D | vfio.rst | 2 VFIO device migration
13 transferred. The iterative pre-copy phase of migration allows for the guest to
20 enabling "switchover-ack" migration capability.
21 VFIO migration uAPI defines "initial bytes" as part of its pre-copy data stream
23 before stopping the source VM. Enabling this migration capability will
26 To support migration of multiple devices that might do P2P transactions between
27 themselves, VFIO migration uAPI defines an intermediate P2P quiescent state.
33 All the devices that support P2P migration are first transitioned to the P2P
34 quiescent state and only then are they stopped or started. This makes migration
38 Thus, multiple VFIO devices migration is allowed only if all the devices
[all …]
|
| H A D | main.rst | 18 requested: migration. This means that QEMU is able to start in one
22 Next was the "live migration" functionality. This is important
25 migration allows the guest to continue running while the state is
28 unresponsive during live migration is the low hundred of milliseconds
36 The migration stream is normally just a byte stream that can be passed
39 - tcp migration: do the migration using tcp sockets
40 - unix migration: do the migration using unix sockets
41 - exec migration: do the migration using the stdin/stdout through a process.
42 - fd migration: do the migration using a file descriptor that is
44 - file migration: do the migration using a file that is passed to QEMU
[all …]
|
| H A D | mapped-ram.rst | 5 supplement the existing ``file:`` migration and make it compatible
6 with ``multifd``. This enables parallel migration of a guest's RAM to
10 directly to offsets in the resulting migration file. This enables the
12 guest is constantly dirtying pages (i.e. live migration). Another
17 usage of O_DIRECT for save/restore of the migration stream as the
31 Use a ``file:`` URL for migration:
33 ``migrate file:/path/to/migration/file``
35 Mapped-ram migration is best done non-live, i.e. by stopping the VM on
45 The mapped-ram feature was designed for use cases where the migration
54 that's the ideal scenario for mapped-ram migration. Not having to
[all …]
|
| H A D | postcopy.rst | 7 'Postcopy' migration is a way to deal with migrations that refuse to converge
9 the amount of migration traffic and time it takes, the down side is that during
16 Postcopy can be combined with precopy (i.e. normal migration) so that if precopy
23 destination) prior to the start of migration:
27 The normal commands are then used to start a migration, which is still
33 It can be issued immediately after migration is started or any
34 time later on. Issuing it after the end of a migration is harmless.
36 Blocktime is a postcopy live migration metric, intended to show how
66 Set at the start of migration if postcopy is enabled, even
70 The destination will fail early in migration at this point if the
[all …]
|
| H A D | best-practices.rst | 8 The migration stream can be analyzed thanks to ``scripts/analyze-migration.py``.
17 $ ./scripts/analyze-migration.py -f mig
24 See also ``analyze-migration.py -h`` help for more options.
35 to hold the firmware and thus migration can fail. In practice it's best
40 emulation code can work with older firmware to allow forward migration.
42 - Care should be taken with newer firmware so that backward migration
|
| H A D | compatibility.rst | 7 When we do migration, we have two QEMU processes: the source and the
29 First of all, migration is only supposed to work if you use the same
77 This migration is known as newer to older. We need to make sure
79 migration to qemu-5.1. Notice that we can't make updates to
85 This migration is known as older to newer. We need to make sure
133 When we are doing migration, if we migrate from a device that has 4
136 migration.
154 correct. migration works.
161 correct. migration works.
183 migration A -> B is case 6, so number of queues needs to be 1.
[all …]
|
| H A D | index.rst | 4 This is the main entry for QEMU migration documentations. It explains how
5 QEMU live migration works.
|
| /openbmc/linux/Documentation/mm/ |
| H A D | page_migration.rst | 2 Page migration
5 Page migration allows moving the physical location of pages between
13 The main intent of page migration is to reduce the latency of memory accesses
17 Page migration allows a process to manually relocate the node on which its
23 Page migration functions are provided by the numactl package by Andi Kleen
27 migration. cat ``/proc/<pid>/numa_maps`` allows an easy review of where the
31 Manual migration is useful if for example the scheduler has relocated
35 manual page migration support. Automatic page migration may be implemented
52 Page migration allows the preservation of the relative location of pages
53 within a group of nodes for all migration techniques which will preserve a
[all …]
|
| /openbmc/qemu/docs/ |
| H A D | multi-thread-compression.txt | 1 Use multiple thread (de)compression in live migration
21 be decompressed. Using compression in live migration can help
23 bandwidth is limited, and the total migration time can also be reduced
28 extra CPU cycles will increase the migration time. On the other hand,
30 the total migration time. If the process of the compression is quick
31 enough, then the total migration time can be reduced, and multiple
46 When to use the multiple thread compression in live migration
53 can still help to reduce the migration time.
112 to support the multiple thread compression migration:
128 6. Start outgoing migration:
[all …]
|
| H A D | rdma.txt | 28 RDMA helps make your migration more deterministic under heavy load because
32 migration, under certain types of memory-bound workloads, may take a more
33 unpredictable amount of time to complete the migration if the amount of
34 memory tracked during each live migration iteration round cannot keep pace
39 migration using RDMA is capable of using both technologies because of
52 Use of RDMA during migration requires pinning and registering memory
56 of RDMA migration may in fact be harmful to co-located VMs or other
59 use of RDMA is discouraged and it is recommended to use standard TCP migration.
65 bulk-phase round of the migration and can be enabled for extremely
75 of the migration, which can greatly reduce the "total" time of your migration.
[all …]
|
| /openbmc/qemu/tests/qemu-iotests/ |
| H A D | 234.out | 2 Enabling migration QMP events on A...
5 Enabling migration QMP events on B...
9 Starting migration to B...
23 Enabling migration QMP events on A...
26 Starting migration back to A...
|
| H A D | 262.out | 2 Enabling migration QMP events on B...
5 Enabling migration QMP events on A...
7 Starting migration to B...
|
| H A D | 091.out | 13 vm1: live migration started
14 vm1: live migration completed
16 === VM 2: Post-migration, write to disk, verify running ===
|
| /openbmc/linux/tools/testing/selftests/mm/ |
| H A D | migration.c | 23 FIXTURE(migration) in FIXTURE() argument
32 FIXTURE_SETUP(migration) in FIXTURE_SETUP() argument
57 FIXTURE_TEARDOWN(migration) in FIXTURE_TEARDOWN() argument
118 TEST_F_TIMEOUT(migration, private_anon, 2*RUNTIME)
143 TEST_F_TIMEOUT(migration, shared_anon, 2*RUNTIME)
178 TEST_F_TIMEOUT(migration, private_anon_thp, 2*RUNTIME)
|
| /openbmc/linux/Documentation/ABI/testing/ |
| H A D | sysfs-kernel-mm-numa | 11 Page migration during reclaim is intended for systems
16 Allowing page migration during reclaim enables these
18 when the fast tier is under pressure. This migration
|
| /openbmc/qemu/migration/ |
| H A D | meson.build | 3 'migration-stats.c',
22 'migration-hmp-cmds.c',
23 'migration.c',
|
| /openbmc/qemu/docs/system/ |
| H A D | virtio-net-failover.rst | 9 virtio-net device. Before migration the vfio device is unplugged and data flows
29 Virtio-net standby allows easy migration while using a passed-through fast
31 the migration. It is like a simple version of a bond, the difference is that it
64 A new migration state wait-unplug was added for this feature. If failover primary
65 devices are present in the configuration, migration will go into this state.
|