From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> RDMA migration currently relies on the source and destination RAMBlocks having the same offsets within ram_addr_t space; unfortunately that's just not true when: a) You hotplug on the source but then create the device on the command line on the destination.
b) Across two versions of qemu Thus there are migrations that work with TCP that don't with RDMA. The changes keep stream compatibility with existing RDMA migration, so cases that already work (i.e. no hotplug) will keep working. The new requirements do rely on the block indexes being the same on both sides (hence we sort to ensure that), my reading of the existing code is that it also relies on that in various places but doesn't ensure it's true. With some light testing this seems to work; hopefully I've got all the cases that pass offsets back and forward. v2: Keep rdma_delete_block's ability to delete entries from the hash (on the source side) Fix ram-control-hook modification so they don't break non-rdma migrate Added a fix that makes the RDMA migration exit in the case of some mismatched configs instead of hanging. Clarified comments/commit messages Added a pair of typo fixes Dr. David Alan Gilbert (12): Rename RDMA structures to make destination clear qemu_ram_foreach_block: pass up error value, and down the ramblock name Remove unneeded memset rdma typos Store block name in local blocks structure Translate offsets to destination address space Rework ram_control_load_hook to hook during block load Allow rdma_delete_block to work without the hash Rework ram block hash Sort destination RAMBlocks to be the same as the source Sanity check RDMA remote data Fail more cleanly in mismatched RAM cases arch_init.c | 4 +- exec.c | 10 +- include/exec/cpu-common.h | 4 +- include/migration/migration.h | 2 +- include/migration/qemu-file.h | 14 +- migration/qemu-file.c | 16 +- migration/rdma.c | 347 +++++++++++++++++++++++++++++------------- trace-events | 12 +- 8 files changed, 279 insertions(+), 130 deletions(-) -- 2.4.2