[v3] Make switchover-ack re-usable and add VFIO precopy REINIT feature

[PATCH v3 02/14] migration/ram: Use migration_bitmap_sync_precopy() for postcopy discard

Avihai Horon posted 14 patches 2 months ago

Diff against v1 v2 v4 v5
Download mbox

Maintainers: Alex Williamson <alex@shazbot.org>, "Cédric Le Goater" <clg@redhat.com>, Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>, Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>, "Philippe Mathieu-Daudé" <philmd@mailo.com>, Zhao Liu <zhao1.liu@intel.com>, Halil Pasic <pasic@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, Jason Herne <jjherne@linux.ibm.com>, Richard Henderson <richard.henderson@linaro.org>, Ilya Leoshkevich <iii@linux.ibm.com>, David Hildenbrand <david@kernel.org>, Eric Farman <farman@linux.ibm.com>, Matthew Rosato <mjrosato@linux.ibm.com>, Cornelia Huck <cohuck@redhat.com>, Eric Blake <eblake@redhat.com>, Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>, John Snow <jsnow@redhat.com>, Markus Armbruster <armbru@redhat.com>

There is a newer version of this series

Expand all Fold all

[PATCH v3 02/14] migration/ram: Use migration_bitmap_sync_precopy() for postcopy discard

Posted by Avihai Horon 2 months ago

ram_postcopy_send_discard_bitmap() performs the final RAM dirty bitmap
sync at postcopy switchover, before sending discard bitmap to the
destination. Unlike the precopy switchover path, it currently calls the
raw migration_bitmap_sync() helper and passes last_stage=false.

Postcopy switchover is also a stopped-VM final sync point, so use
migration_bitmap_sync_precopy(true). This keeps RAM final bitmap sync
handling consistent across precopy and postcopy switchover, including
the precopy bitmap-sync notifier wrapper. Current notifier users are
safe in postcopy: virtio-balloon free-page hinting already opts out when
postcopy-ram is enabled [1].

This prepares for moving the final sync out of RAM completion/discard
paths and into migration_switchover_start(), where the migration core
can run a final save_query_pending pass for all modules uniformly.

[1] fd51e54fa102 ("virtio-balloon: don't start free page hinting if postcopy is possible")

Signed-off-by: Avihai Horon <avihaih@nvidia.com>
---
 migration/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index fc38ffbf8a..d7b8cc61ea 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2684,7 +2684,7 @@ void ram_postcopy_send_discard_bitmap(MigrationState *ms)
     RCU_READ_LOCK_GUARD();
 
     /* This should be our last sync, the src is now paused */
-    migration_bitmap_sync(rs, false);
+    migration_bitmap_sync_precopy(true);
 
     /* Easiest way to make sure we don't resume in the middle of a host-page */
     rs->pss[RAM_CHANNEL_PRECOPY].last_sent_block = NULL;
-- 
2.40.1

Re: [PATCH v3 02/14] migration/ram: Use migration_bitmap_sync_precopy() for postcopy discard

Posted by Peter Xu 2 months ago

On Tue, Jun 09, 2026 at 10:58:00AM +0300, Avihai Horon wrote:
> ram_postcopy_send_discard_bitmap() performs the final RAM dirty bitmap
> sync at postcopy switchover, before sending discard bitmap to the
> destination. Unlike the precopy switchover path, it currently calls the
> raw migration_bitmap_sync() helper and passes last_stage=false.
> 
> Postcopy switchover is also a stopped-VM final sync point, so use
> migration_bitmap_sync_precopy(true). This keeps RAM final bitmap sync
> handling consistent across precopy and postcopy switchover, including
> the precopy bitmap-sync notifier wrapper. Current notifier users are
> safe in postcopy: virtio-balloon free-page hinting already opts out when
> postcopy-ram is enabled [1].
> 
> This prepares for moving the final sync out of RAM completion/discard
> paths and into migration_switchover_start(), where the migration core
> can run a final save_query_pending pass for all modules uniformly.
> 
> [1] fd51e54fa102 ("virtio-balloon: don't start free page hinting if postcopy is possible")
> 
> Signed-off-by: Avihai Horon <avihaih@nvidia.com>

Reviewed-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu