ShuriZma
/
xemu
mirror of https://github.com/xemu-project/xemu.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
xemu/docs/devel/migration/features.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

14 lines
194 B
ReStructuredText
Raw Normal View History

docs/migration: Split "Postcopy" Split postcopy into a separate file. Introduce a head page "features.rst" to keep all the features on top of migration framework. Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/r/20240109064628.595453-7-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
2024-01-09 06:46:24 +00:00
Migration features
==================
Migration has plenty of features to support different use cases.
.. toctree::
:maxdepth: 2
postcopy
docs/migration: Split "dirty limit" Split that into a separate file, put under "features". Cc: Yong Huang <yong.huang@smartx.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/r/20240109064628.595453-8-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
2024-01-09 06:46:25 +00:00
dirty-limit
docs/migration: Further move vfio to be feature of migration Move it one layer down, so taking VFIO-migration as a feature for migration. Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/r/20240109064628.595453-10-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
2024-01-09 06:46:27 +00:00
vfio
docs/migration: Further move virtio to be feature of migration Move it one layer down, so taking Virtio-migration as a feature for migration. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/r/20240109064628.595453-11-peterx@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
2024-01-09 06:46:28 +00:00
virtio
migration/ram: Introduce 'mapped-ram' migration capability Add a new migration capability 'mapped-ram'. The core of the feature is to ensure that RAM pages are mapped directly to offsets in the resulting migration file instead of being streamed at arbitrary points. The reasons why we'd want such behavior are: - The resulting file will have a bounded size, since pages which are dirtied multiple times will always go to a fixed location in the file, rather than constantly being added to a sequential stream. This eliminates cases where a VM with, say, 1G of RAM can result in a migration file that's 10s of GBs, provided that the workload constantly redirties memory. - It paves the way to implement O_DIRECT-enabled save/restore of the migration stream as the pages are ensured to be written at aligned offsets. - It allows the usage of multifd so we can write RAM pages to the migration file in parallel. For now, enabling the capability has no effect. The next couple of patches implement the core functionality. Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-8-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
2024-02-29 15:30:01 +00:00
mapped-ram