@samitouri / QOSamiQemu / commits / 4abebba9f1

migration: Fix "switchover" used as a verb in comments and docs

"Switchover" is a noun; the verb form is "switch over". Replace all instances where "switchover" was incorrectly used as a verb in comments and documentation. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20260706085211.13905-17-avihaih@nvidia.com Signed-off-by: Cédric Le Goater <clg@redhat.com>

Avihai Horon committed Jul 6, 2026 at 11:52 UTC 4abebba9f1e9e1de6d5e497ccc5f64f5dbac4359
4 files changed +8 -8
migration/migration.c
+2 -2
@@ -3293,7 +3293,7 @@ static bool migration_iteration_next_ready(MigrationState *s,
3293 MigPendingData *pending)
3294 {
3295 /*
3296 - * If the estimated values already suggest us to switchover, mark this
3296 + * If the estimated values already suggest us to switch over, mark this
3297 * iteration finished, time to do a slow sync.
3298 */
3299 if (pending->total_bytes <= s->threshold_size) {
@@ -3418,7 +3418,7 @@ static MigIterateState migration_iteration_run(MigrationState *s)
3418 migration_iteration_go_next(s, &pending);
3419 }
3420
3421 - /* Check can switchover after qemu_savevm_query_pending() */
3421 + /* Check if we can switch over after qemu_savevm_query_pending() */
3422 can_switchover = migration_can_switchover(s);
3423
3424 /* Should we switch to postcopy now? */
migration/migration.h
+3 -3
@@ -496,12 +496,12 @@ struct MigrationState {
496 * migration progresses, the devices on the destination acknowledge
497 * switchover, decreasing the counter. When the counter reaches zero, a
498 * single ACK message is sent to the source via the return path, indicating
499 - * that it's OK to switchover.
499 + * that it's OK to switch over.
500 *
501 * In new switchover-ack, the source is the one that keeps track of a
502 * pending ACKs counter. As migration progresses, the destination sends ACK
503 * message per-device via the return path, which decrements the source
504 - * counter. When the counter reaches zero, it's OK to switchover. During
504 + * counter. When the counter reaches zero, it's OK to switch over. During
505 * precopy, source-side devices may request additional ACKs, which increment
506 * the counter again.
507 *
@@ -521,7 +521,7 @@ struct MigrationState {
521 /*
522 * Indicates the number of pending ACKs from the destination. The value may
523 * increase or decrease during precopy as new ACKs are requested or
524 - * received. When zero is reached, it's OK to switchover. In legacy
524 + * received. When zero is reached, it's OK to switch over. In legacy
525 * switchover-ack, it's initialized to 1 and decreased to zero upon ACK.
526 */
527 uint32_t switchover_ack_pending_num;
migration/savevm.c
+1 -1
@@ -2509,7 +2509,7 @@ static int loadvm_postcopy_handle_switchover_start(Error **errp)
2509
2510 /*
2511 * If legacy switchover-ack is enabled but no device uses it, need to send an
2512 - * ACK to source that it's OK to switchover.
2512 + * ACK to source that it's OK to switch over.
2513 */
2514 static int loadvm_switchover_ack_no_users_legacy(MigrationIncomingState *mis,
2515 Error **errp)
qapi/migration.json
+2 -2
@@ -509,7 +509,7 @@
509 #
510 # @switchover-ack: If enabled, migration will not stop the source VM
511 # and complete the migration until the destination has
512 -# acknowledged that it is OK to switchover. The acknowledgement
512 +# acknowledged that it is OK to switch over. The acknowledgement
513 # may depend, for example, on some device's data being loaded in
514 # the destination before doing switchover. This can reduce
515 # downtime if devices that support this capability are present.
@@ -919,7 +919,7 @@
919 # migration can use during switchover phase, in bytes per
920 # second. **Note:** this does not limit the bandwidth during
921 # switchover, but only for calculations when making decisions to
922 -# switchover. By default, this value is zero, which means QEMU
922 +# switch over. By default, this value is zero, which means QEMU
923 # will estimate the bandwidth automatically. This can be set
924 # when the estimated value is not accurate, while the user is
925 # able to guarantee such bandwidth is available when switching