[PATCH v4 0/8] migration: Introduce POSTCOPY_DEVICE state

Juraj Marcin posted 8 patches 1 week, 3 days ago
Failed in applying to current master (apply log)
migration/migration.c                 | 123 +++++++++++++-------
migration/migration.h                 |   4 +
migration/postcopy-ram.c              | 161 ++++++++++++++++++++++++++
migration/postcopy-ram.h              |   3 +
migration/savevm.c                    | 138 ++--------------------
migration/savevm.h                    |   2 +
migration/trace-events                |   3 +-
qapi/migration.json                   |  10 +-
tests/qemu-iotests/194                |   2 +-
tests/qtest/migration/precopy-tests.c |   3 +-
10 files changed, 275 insertions(+), 174 deletions(-)
[PATCH v4 0/8] migration: Introduce POSTCOPY_DEVICE state
Posted by Juraj Marcin 1 week, 3 days ago
This series introduces a new POSTCOPY_DEVICE state that is active (both,
on source and destination side), while the destination loads the device
state. Before this series, if the destination machine failed during the
device load, the source side would stay stuck POSTCOPY_ACTIVE with no
way of recovery. With this series, if the migration fails while in
POSTCOPY_DEVICE state, the source side can safely resume, as destination
has not started yet.

RFC: https://lore.kernel.org/all/20250807114922.1013286-1-jmarcin@redhat.com/

V1: https://lore.kernel.org/all/20250915115918.3520735-1-jmarcin@redhat.com/

V2: https://lore.kernel.org/all/20251027154115.4138677-1-jmarcin@redhat.com/

V3: https://lore.kernel.org/all/20251030214915.1411860-1-jmarcin@redhat.com/

V4 changes:

- fixes for failing qemu-iotest 194
    - flush channel after sending CMD_PACKAGED data (new patch 1)
    - POSTCOPY_DEVICE state is now used only if return-path is open

Juraj Marcin (7):
  migration: Flush migration channel after sending data of CMD_PACKAGED
  migration: Move postcopy_ram_listen_thread() to postcopy-ram.c
  migration: Introduce postcopy incoming setup and cleanup functions
  migration: Refactor all incoming cleanup info
    migration_incoming_destroy()
  migration: Respect exit-on-error when migration fails before resuming
  migration: Make postcopy listen thread joinable
  migration: Introduce POSTCOPY_DEVICE state

Peter Xu (1):
  migration: Do not try to start VM if disk activation fails

 migration/migration.c                 | 123 +++++++++++++-------
 migration/migration.h                 |   4 +
 migration/postcopy-ram.c              | 161 ++++++++++++++++++++++++++
 migration/postcopy-ram.h              |   3 +
 migration/savevm.c                    | 138 ++--------------------
 migration/savevm.h                    |   2 +
 migration/trace-events                |   3 +-
 qapi/migration.json                   |  10 +-
 tests/qemu-iotests/194                |   2 +-
 tests/qtest/migration/precopy-tests.c |   3 +-
 10 files changed, 275 insertions(+), 174 deletions(-)

-- 
2.51.0
Re: [PATCH v4 0/8] migration: Introduce POSTCOPY_DEVICE state
Posted by Peter Xu 1 week, 3 days ago
On Mon, Nov 03, 2025 at 07:32:49PM +0100, Juraj Marcin wrote:
> This series introduces a new POSTCOPY_DEVICE state that is active (both,
> on source and destination side), while the destination loads the device
> state. Before this series, if the destination machine failed during the
> device load, the source side would stay stuck POSTCOPY_ACTIVE with no
> way of recovery. With this series, if the migration fails while in
> POSTCOPY_DEVICE state, the source side can safely resume, as destination
> has not started yet.
> 
> RFC: https://lore.kernel.org/all/20250807114922.1013286-1-jmarcin@redhat.com/
> 
> V1: https://lore.kernel.org/all/20250915115918.3520735-1-jmarcin@redhat.com/
> 
> V2: https://lore.kernel.org/all/20251027154115.4138677-1-jmarcin@redhat.com/
> 
> V3: https://lore.kernel.org/all/20251030214915.1411860-1-jmarcin@redhat.com/
> 
> V4 changes:
> 
> - fixes for failing qemu-iotest 194
>     - flush channel after sending CMD_PACKAGED data (new patch 1)
>     - POSTCOPY_DEVICE state is now used only if return-path is open

Queued, thanks Juraj.

-- 
Peter Xu