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>
This commit is contained in:
Avihai Horon
2026-07-06 11:52:11 +03:00
committed by Cédric Le Goater
parent 511b786d13
commit 4abebba9f1
4 changed files with 8 additions and 8 deletions

View File

@@ -3293,7 +3293,7 @@ static bool migration_iteration_next_ready(MigrationState *s,
MigPendingData *pending)
{
/*
* If the estimated values already suggest us to switchover, mark this
* If the estimated values already suggest us to switch over, mark this
* iteration finished, time to do a slow sync.
*/
if (pending->total_bytes <= s->threshold_size) {
@@ -3418,7 +3418,7 @@ static MigIterateState migration_iteration_run(MigrationState *s)
migration_iteration_go_next(s, &pending);
}
/* Check can switchover after qemu_savevm_query_pending() */
/* Check if we can switch over after qemu_savevm_query_pending() */
can_switchover = migration_can_switchover(s);
/* Should we switch to postcopy now? */

View File

@@ -496,12 +496,12 @@ struct MigrationState {
* migration progresses, the devices on the destination acknowledge
* switchover, decreasing the counter. When the counter reaches zero, a
* single ACK message is sent to the source via the return path, indicating
* that it's OK to switchover.
* that it's OK to switch over.
*
* In new switchover-ack, the source is the one that keeps track of a
* pending ACKs counter. As migration progresses, the destination sends ACK
* message per-device via the return path, which decrements the source
* counter. When the counter reaches zero, it's OK to switchover. During
* counter. When the counter reaches zero, it's OK to switch over. During
* precopy, source-side devices may request additional ACKs, which increment
* the counter again.
*
@@ -521,7 +521,7 @@ struct MigrationState {
/*
* Indicates the number of pending ACKs from the destination. The value may
* increase or decrease during precopy as new ACKs are requested or
* received. When zero is reached, it's OK to switchover. In legacy
* received. When zero is reached, it's OK to switch over. In legacy
* switchover-ack, it's initialized to 1 and decreased to zero upon ACK.
*/
uint32_t switchover_ack_pending_num;

View File

@@ -2509,7 +2509,7 @@ static int loadvm_postcopy_handle_switchover_start(Error **errp)
/*
* If legacy switchover-ack is enabled but no device uses it, need to send an
* ACK to source that it's OK to switchover.
* ACK to source that it's OK to switch over.
*/
static int loadvm_switchover_ack_no_users_legacy(MigrationIncomingState *mis,
Error **errp)

View File

@@ -509,7 +509,7 @@
#
# @switchover-ack: If enabled, migration will not stop the source VM
# and complete the migration until the destination has
# acknowledged that it is OK to switchover. The acknowledgement
# acknowledged that it is OK to switch over. The acknowledgement
# may depend, for example, on some device's data being loaded in
# the destination before doing switchover. This can reduce
# downtime if devices that support this capability are present.
@@ -919,7 +919,7 @@
# migration can use during switchover phase, in bytes per
# second. **Note:** this does not limit the bandwidth during
# switchover, but only for calculations when making decisions to
# switchover. By default, this value is zero, which means QEMU
# switch over. By default, this value is zero, which means QEMU
# will estimate the bandwidth automatically. This can be set
# when the estimated value is not accurate, while the user is
# able to guarantee such bandwidth is available when switching