diff options
| author | Li Zhijian <lizhijian@fujitsu.com> | 2025-03-05 14:28:21 +0800 |
|---|---|---|
| committer | Peter Xu <peterx@redhat.com> | 2025-05-02 11:09:36 -0400 |
| commit | 57be554c2984de3261d1e5d446d797d8e5b2c997 (patch) | |
| tree | bcc6eb9efc6030668fc4fd281b7f2e0beebd2960 /rust | |
| parent | 5134cf9b5d3aee4475fe7e1c1c11b093731073cf (diff) | |
| download | qemu-57be554c2984de3261d1e5d446d797d8e5b2c997.zip qemu-57be554c2984de3261d1e5d446d797d8e5b2c997.tar.gz qemu-57be554c2984de3261d1e5d446d797d8e5b2c997.tar.bz2 | |
migration: check RDMA and capabilities are compatible on both sides
Depending on the order of starting RDMA and setting capability,
they can be categorized into the following scenarios:
Source:
S1: [set capabilities] -> [Start RDMA outgoing]
Destination:
D1: [set capabilities] -> [Start RDMA incoming]
D2: [Start RDMA incoming] -> [set capabilities]
Previously, compatibility between RDMA and capabilities was verified only
in scenario D1, potentially causing migration failures in other situations.
For scenarios S1 and D1, we can seamlessly incorporate
migration_transport_compatible() to address compatibility between
channels and capabilities vs transport.
For scenario D2, ensure compatibility within migrate_caps_check().
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Message-ID: <20250305062825.772629-3-lizhijian@fujitsu.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Diffstat (limited to 'rust')
0 files changed, 0 insertions, 0 deletions