On 3/12/26 11:08 AM, Peter Maydell wrote:
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.
Reporting errors is useful when there is a possibility to recover from
it, but in this case it seems like we can only stop when user try to
request time control, so I'm not sure we should return anything from
this function at all instead of crashing.
thanks
-- PMM
