On 3/12/24 08:16, Cédric Le Goater wrote:
On 3/11/24 21:24, Peter Xu wrote:
On Fri, Mar 08, 2024 at 04:15:08PM +0800, Peter Xu wrote:
On Wed, Mar 06, 2024 at 02:34:15PM +0100, Cédric Le Goater wrote:
* [1-4] already queued in migration-next.
migration: Report error when shutdown fails
migration: Remove SaveStateHandler and LoadStateHandler typedefs
migration: Add documentation for SaveVMHandlers
migration: Do not call PRECOPY_NOTIFY_SETUP notifiers in case of error
* [5-9] are prequisite changes in other components related to the
migration save_setup() handler. They make sure a failure is not
returned without setting an error.
s390/stattrib: Add Error** argument to set_migrationmode() handler
vfio: Always report an error in vfio_save_setup()
migration: Always report an error in block_save_setup()
migration: Always report an error in ram_save_setup()
migration: Add Error** argument to vmstate_save()
* [10-15] are the core changes in migration and memory components to
propagate an error reported in a save_setup() handler.
migration: Add Error** argument to qemu_savevm_state_setup()
migration: Add Error** argument to .save_setup() handler
migration: Add Error** argument to .load_setup() handler
Further queued 5-12 in migration-staging (until here), thanks.
Just to keep a record: due to the virtio failover test failure and the
other block migration uncertainty in patch 7 (in which case we may want to
have a fix on sectors==0 case), I unqueued this chunk for 9.0.
ok. I will ask the block folks for help to understand if sectors==0
is also an error in the save_setup context. May be we can still
merge these in 9.0 cycle.
I discussed with Kevin and sectors==0 is not an error case, the loop
should simply continue. That said, commit 66db46ca83b8 ("migration:
Deprecate block migration") would let us remove all that code in
the next cycle which is even simpler.
Thanks,
C.
