aboutsummaryrefslogtreecommitdiff
path: root/hw/ppc
diff options
context:
space:
mode:
authorMarkus Armbruster <armbru@redhat.com>2021-07-20 14:53:55 +0200
committerMarkus Armbruster <armbru@redhat.com>2021-08-26 17:15:28 +0200
commitd7f5013e122e14c6f5ac8d973e6567413cfa3790 (patch)
treec1a5034cf601d4f8eb19570dddba5963ea17b33d /hw/ppc
parente2ef4fc7aeb7e5856594f3172e08e6650011084a (diff)
spapr: Explain purpose of ->fwnmi_migration_blocker more clearly
spapr_mce_req_event() makes an effort to prevent migration from degrading the reporting of FWNMIs. It adds a migration blocker when it receives one, and deletes it when it's done handling it. This is a best effort. Commit 2500fb423a "migration: Include migration support for machine check handling" tried to explain this in a comment. Rewrite the comment for clarity, and reposition it to make it clear it applies to all failure modes, not just "migration already in progress". Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Aravinda Prasad <arawinda.p@gmail.com> Cc: Ganesh Goudar <ganeshgr@linux.ibm.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210720125408.387910-4-armbru@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Diffstat (limited to 'hw/ppc')
-rw-r--r--hw/ppc/spapr_events.c17
1 files changed, 9 insertions, 8 deletions
diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
index 690533cbdc..630e86282c 100644
--- a/hw/ppc/spapr_events.c
+++ b/hw/ppc/spapr_events.c
@@ -911,16 +911,17 @@ void spapr_mce_req_event(PowerPCCPU *cpu, bool recovered)
}
}
+ /*
+ * Try to block migration while FWNMI is being handled, so the
+ * machine check handler runs where the information passed to it
+ * actually makes sense. This shouldn't actually block migration,
+ * only delay it slightly, assuming migration is retried. If the
+ * attempt to block fails, carry on. Unfortunately, it always
+ * fails when running with -only-migrate. A proper interface to
+ * delay migration completion for a bit could avoid that.
+ */
ret = migrate_add_blocker(spapr->fwnmi_migration_blocker, NULL);
if (ret == -EBUSY) {
- /*
- * We don't want to abort so we let the migration to continue.
- * In a rare case, the machine check handler will run on the target.
- * Though this is not preferable, it is better than aborting
- * the migration or killing the VM. It is okay to call
- * migrate_del_blocker on a blocker that was not added (which the
- * nmi-interlock handler would do when it's called after this).
- */
warn_report("Received a fwnmi while migration was in progress");
}