From: Aadeshveer Singh <aadeshveer07@gmail.com>
To: qemu-devel@nongnu.org
Cc: peterx@redhat.com, farosas@suse.de, pbonzini@redhat.com,
philmd@mailo.com, lvivier@redhat.com, ayoub@saferwall.com,
Aadeshveer Singh <aadeshveer07@gmail.com>
Subject: [RFC PATCH v2 3/7] migration: Use file_bmap for RAMBlock during incoming file load
Date: Tue, 30 Jun 2026 13:49:36 +0530 [thread overview]
Message-ID: <20260630081940.611092-4-aadeshveer07@gmail.com> (raw)
In-Reply-To: <20260630081940.611092-1-aadeshveer07@gmail.com>
Replace the temporary bitmap with the existing file_bmap attribute of
the RAMBlock. This acts as a preparatory change for the upcoming fast
snapshot load feature.
Reusing this bitmap allows the destination to track page types during
a postcopy load, enabling faster, direct placement of zero pages.
Since file_bmap is currently only utilized during the migration save
phase, it can be safely repurposed during the load phase without
introducing conflicts.
Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
---
migration/ram.c | 33 +++++++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index fc38ffbf8a..4728f14d73 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -252,6 +252,17 @@ int foreach_not_ignored_block(RAMBlockIterFunc func, void *opaque)
return ret;
}
+static void ramblock_file_bmap_init(void)
+{
+ RAMBlock *rb;
+
+ RAMBLOCK_FOREACH_NOT_IGNORED(rb) {
+ assert(!rb->file_bmap);
+ size_t size = rb->max_length >> qemu_target_page_bits();
+ rb->file_bmap = bitmap_new(size);
+ }
+}
+
static void ramblock_recv_map_init(void)
{
RAMBlock *rb;
@@ -3749,6 +3760,9 @@ static int ram_load_setup(QEMUFile *f, void *opaque, Error **errp)
{
xbzrle_load_setup();
ramblock_recv_map_init();
+ if (migrate_mapped_ram()) {
+ ramblock_file_bmap_init();
+ }
return 0;
}
@@ -3766,8 +3780,8 @@ static int ram_load_cleanup(void *opaque)
xbzrle_load_cleanup();
RAMBLOCK_FOREACH_NOT_IGNORED(rb) {
- g_free(rb->receivedmap);
- rb->receivedmap = NULL;
+ g_clear_pointer(&rb->receivedmap, g_free);
+ g_clear_pointer(&rb->file_bmap, g_free);
}
return 0;
@@ -4142,11 +4156,18 @@ err:
static void parse_ramblock_mapped_ram(QEMUFile *f, RAMBlock *block,
ram_addr_t length, Error **errp)
{
- g_autofree unsigned long *bitmap = NULL;
MappedRamHeader header;
size_t bitmap_size;
long num_pages;
+ if (length > block->max_length) {
+ error_setg(errp,
+ "mapped-ram header length %" PRIu64 " exceeds "
+ "RAMBlock(\"%s\") max_length %" PRIu64,
+ (uint64_t)length, block->idstr, (uint64_t)block->max_length);
+ return;
+ }
+
if (!mapped_ram_read_header(f, &header, errp)) {
return;
}
@@ -4174,14 +4195,14 @@ static void parse_ramblock_mapped_ram(QEMUFile *f, RAMBlock *block,
num_pages = length / header.page_size;
bitmap_size = BITS_TO_LONGS(num_pages) * sizeof(unsigned long);
- bitmap = g_malloc0(bitmap_size);
- if (qemu_get_buffer_at(f, (uint8_t *)bitmap, bitmap_size,
+ if (qemu_get_buffer_at(f, (uint8_t *)block->file_bmap, bitmap_size,
header.bitmap_offset) != bitmap_size) {
error_setg(errp, "Error reading dirty bitmap");
return;
}
- if (!read_ramblock_mapped_ram(f, block, num_pages, bitmap, errp)) {
+ if (!read_ramblock_mapped_ram(f, block, num_pages, block->file_bmap,
+ errp)) {
return;
}
--
2.54.0
next prev parent reply other threads:[~2026-06-30 8:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 8:19 [RFC PATCH v2 0/7] migration: fast snapshot load Aadeshveer Singh
2026-06-30 8:19 ` [RFC PATCH v2 1/7] migration/tests: remove capability conflict test postcopy-ram+mapped-ram Aadeshveer Singh
2026-07-06 19:02 ` Peter Xu
2026-06-30 8:19 ` [RFC PATCH v2 2/7] migration: Propagate error in postcopy setup functions Aadeshveer Singh
2026-07-06 19:13 ` Peter Xu
2026-06-30 8:19 ` Aadeshveer Singh [this message]
2026-07-06 19:29 ` [RFC PATCH v2 3/7] migration: Use file_bmap for RAMBlock during incoming file load Peter Xu
2026-06-30 8:19 ` [RFC PATCH v2 4/7] migration: Make qemu_get_buffer_at() thread-safe Aadeshveer Singh
2026-07-06 19:34 ` Peter Xu
2026-06-30 8:19 ` [RFC PATCH v2 5/7] migration: add RAMBlock field and helper for fast snapshot load Aadeshveer Singh
2026-07-06 20:03 ` Peter Xu
2026-06-30 8:19 ` [RFC PATCH v2 6/7] migration: add support for fault thread to load pages from disk Aadeshveer Singh
2026-07-06 20:35 ` Peter Xu
2026-06-30 8:19 ` [RFC PATCH v2 7/7] migration: add eager load thread and setup for fast snapshot load Aadeshveer Singh
2026-07-06 21:07 ` Peter Xu
2026-07-06 19:16 ` [RFC PATCH v2 0/7] migration: " Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260630081940.611092-4-aadeshveer07@gmail.com \
--to=aadeshveer07@gmail.com \
--cc=ayoub@saferwall.com \
--cc=farosas@suse.de \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@mailo.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.