Peter Xu <[email protected]> writes: > On Fri, Jan 23, 2026 at 09:59:35AM -0300, Fabiano Rosas wrote: >> Peter Xu <[email protected]> writes: >> >> > Devices may opt-in migration FAILED notifiers to be invoked when migration >> > fails. Currently, the notifications happen in migration_cleanup(). It is >> > normally fine, but maybe not ideal if there's dependency of the fallback >> > v.s. VM starts. >> > >> > This patch moves the FAILED notification earlier, so that if the failure >> > happened during switchover, it'll notify before VM restart. >> > >> >> The change to FAILED in patch 2 should come to this patch to avoid >> having a window where the notification only happens at the end. > > Hmm.. Isn't that expected? Even after patch 2, we still notify FAILED at > the end for precopy. It's the same for postcopy. >
Sorry, I meant: s/at the end/after vm_start/. > For a failed postcopy we have following behavior: > > Before patch 2 > ============== > > - notify FAILED (during switchover) > - vm_start() > - notify FAILED (during migration_cleanup) > > After patch 2 > ============= > > - vm_start() > - notify FAILED (during migration_cleanup) > > So patch 2 fixes the duplicate issue, and only fixes that. > > After patch 3 > ============= > > - notify FAILED (during migration_iteration_finish) > - vm_start() > > Patch 3 changes the place of FAILED notification so that it happens always > before vm_start(), for both precopy and postcopy. Right, my point is that with patch 3 we're establishing that the correct place to notify is before vm_start(). But after patch 2, *if* any driver actually depends on being informed of failure *before* starting the VM, that will not happen. I think both changes could be made at once so that this intermediate state never exists.
