On Thu, 12 Mar 2026 at 18:02, Pierrick Bouvier <[email protected]> wrote: > > On 3/12/26 5:16 AM, Trieu Huynh wrote: > > migrate_add_blocker() can fail (e.g. if migration is already in > > progress), in which case it returns a negative value and populates > > its errp argument with the reason. > > > > The previous code ignored the return value, leaving state > > inconsistent on failure. Fix this by: > > - Passing a local Error ** so failure details can be reported. > > - Checking the return value; on failure, report the error, free the > > migration_blocker Error object, and return NULL to the caller. > > > > Resolves: CID 1645470 > > > > Signed-off-by: Trieu Huynh <[email protected]> > > --- > > plugins/api-system.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > While the description makes sense, how would it happen in real world? > > Plugins usually will request time control on startup (so no migration is > happening). In all cases, plugin who want to control time will have no > other choice than abort. > Maybe we could simply assert that migrate_add_blocker succeeded in this > context.
If the user starts QEMU with the --only-migratable option then all attempts to install migration-blockers will fail. In this case we need to report to the user that the thing they tried to do (use a time-control plugin and also migrate) isn't possible, i.e. exit cleanly with an error rather than falling over. thanks -- PMM
