bwlp/qemu.git/include/migration, branch master

migration: Remove load_state_old and minimum_version_id_old

2022-03-02T18:20:45+00:00

There are no longer any VMStateDescription structs in the tree which use the load_state_old support for custom handling of incoming migration from very old QEMU. Remove the mechanism entirely. This includes removing one stray useless setting of minimum_version_id_old in a VMStateDescription with no load_state_old function, which crept in after the global weeding-out of them in commit 17e313406126. Signed-off-by: Peter Maydell Message-Id: <20220215175705.3846411-1-peter.maydell@linaro.org> Reviewed-by: Dr. David Alan Gilbert Reviewed-by: Francisco Iglesias Reviewed-by: Alistair Francis Signed-off-by: Dr. David Alan Gilbert

Fixed a QEMU hang when guest poweroff in COLO mode

2021-12-15T09:31:42+00:00

When the PVM guest poweroff, the COLO thread may wait a semaphore in colo_process_checkpoint().So, we should wake up the COLO thread before migration shutdown. Signed-off-by: Lei Rao Reviewed-by: Zhang Chen Reviewed-by: Juan Quintela Signed-off-by: Juan Quintela

migration: Add migrate_add_blocker_internal()

2021-11-01T21:56:44+00:00

An internal version that removes -only-migratable implications. It can be used for temporary migration blockers like dump-guest-memory. Reviewed-by: Marc-André Lureau Reviewed-by: Juan Quintela Signed-off-by: Peter Xu Signed-off-by: Juan Quintela

vfio: Support for RamDiscardManager in the vIOMMU case

2021-07-08T19:54:45+00:00

vIOMMU support works already with RamDiscardManager as long as guests only map populated memory. Both, populated and discarded memory is mapped into &address_space_memory, where vfio_get_xlat_addr() will find that memory, to create the vfio mapping. Sane guests will never map discarded memory (e.g., unplugged memory blocks in virtio-mem) into an IOMMU - or keep it mapped into an IOMMU while memory is getting discarded. However, there are two cases where a malicious guests could trigger pinning of more memory than intended. One case is easy to handle: the guest trying to map discarded memory into an IOMMU. The other case is harder to handle: the guest keeping memory mapped in the IOMMU while it is getting discarded. We would have to walk over all mappings when discarding memory and identify if any mapping would be a violation. Let's keep it simple for now and print a warning, indicating that setting RLIMIT_MEMLOCK can mitigate such attacks. We have to take care of incoming migration: at the point the IOMMUs get restored and start creating mappings in vfio, RamDiscardManager implementations might not be back up and running yet: let's add runstate priorities to enforce the order when restoring. Acked-by: Alex Williamson Reviewed-by: Alex Williamson Acked-by: Michael S. Tsirkin Cc: Paolo Bonzini Cc: "Michael S. Tsirkin" Cc: Alex Williamson Cc: Dr. David Alan Gilbert Cc: Igor Mammedov Cc: Pankaj Gupta Cc: Peter Xu Cc: Auger Eric Cc: Wei Yang Cc: teawater Cc: Marek Kedzierski Signed-off-by: David Hildenbrand Message-Id: <20210413095531.25603-10-david@redhat.com> Signed-off-by: Eduardo Habkost

cpu: Move CPUClass::vmsd to SysemuCPUOps

2021-05-26T22:33:59+00:00

Migration is specific to system emulation. - Move the CPUClass::vmsd field to SysemuCPUOps, - restrict VMSTATE_CPU() macro to sysemu, - vmstate_dummy is now unused, remove it. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Message-Id: <20210517105140.1062037-16-f4bug@amsat.org> Signed-off-by: Richard Henderson

migrate/ram: remove "ram_bulk_stage" and "fpo_enabled"

2021-05-13T17:21:13+00:00

The bulk stage is kind of weird: migration_bitmap_find_dirty() will indicate a dirty page, however, ram_save_host_page() will never save it, as migration_bitmap_clear_dirty() detects that it is not dirty. We already fill the bitmap in ram_list_init_bitmaps() with ones, marking everything dirty - it didn't used to be that way, which is why we needed an explicit first bulk stage. Let's simplify: make the bitmap the single source of thuth. Explicitly handle the "xbzrle_enabled after first round" case. Regarding XBZRLE (implicitly handled via "ram_bulk_stage = false" right now), there is now a slight change in behavior: - Colo: When starting, it will be disabled (was implicitly enabled) until the first round actually finishes. - Free page hinting: When starting, XBZRLE will be disabled (was implicitly enabled) until the first round actually finished. - Snapshots: When starting, XBZRLE will be disabled. We essentially only do a single run, so I guess it will never actually get disabled. Postcopy seems to indirectly disable it in ram_save_page(), so there shouldn't be really any change. Cc: "Michael S. Tsirkin" Cc: Juan Quintela Cc: "Dr. David Alan Gilbert" Cc: Andrey Gruzdev Cc: Peter Xu Signed-off-by: David Hildenbrand Message-Id: <20210216105039.40680-1-david@redhat.com> Signed-off-by: Dr. David Alan Gilbert

migration: Inhibit virtio-balloon for the duration of background snapshot

2021-04-06T17:56:01+00:00

The same thing as for incoming postcopy - we cannot deal with concurrent RAM discards when using background snapshot feature in outgoing migration. Fixes: 8518278a6af589ccc401f06e35f171b1e6fae800 (migration: implementation of background snapshot thread) Signed-off-by: Andrey Gruzdev Reported-by: David Hildenbrand Reviewed-by: David Hildenbrand Message-Id: <20210401092226.102804-3-andrey.gruzdev@virtuozzo.com> Signed-off-by: Dr. David Alan Gilbert

migration: introduce a delete_snapshot wrapper

2021-02-08T11:19:51+00:00

Make snapshot deletion consistent with the snapshot save and load commands by using a wrapper around the blockdev layer. The main difference is that we get upfront validation of the passed in device list (if any). Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrangé Message-Id: <20210204124834.774401-10-berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert

migration: wire up support for snapshot device selection

2021-02-08T11:19:51+00:00

Modify load_snapshot/save_snapshot to accept the device list and vmstate node name parameters previously added to the block layer. Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrangé Message-Id: <20210204124834.774401-9-berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert

migration: control whether snapshots are ovewritten

2021-02-08T11:19:51+00:00

The traditional HMP "savevm" command will overwrite an existing snapshot if it already exists with the requested name. This new flag allows this to be controlled allowing for safer behaviour with a future QMP command. Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrangé Message-Id: <20210204124834.774401-8-berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert