From: Hao Xiang <hao.xiang@linux.dev>
To: pbonzini@redhat.com, berrange@redhat.com, eduardo@habkost.net,
peterx@redhat.com, farosas@suse.de, eblake@redhat.com,
armbru@redhat.com, thuth@redhat.com, lvivier@redhat.com,
jdenemar@redhat.com, marcel.apfelbaum@gmail.com,
philmd@linaro.org, wangyanan55@huawei.com, qemu-devel@nongnu.org
Subject: [PATCH v6 2/7] migration/multifd: Allow clearing of the file_bmap from multifd
Date: Mon, 11 Mar 2024 18:00:10 +0000 [thread overview]
Message-ID: <20240311180015.3359271-3-hao.xiang@linux.dev> (raw)
In-Reply-To: <20240311180015.3359271-1-hao.xiang@linux.dev>
From: Fabiano Rosas <farosas@suse.de>
We currently only need to clear the mapped-ram file bitmap from the
migration thread during save_zero_page.
We're about to add support for zero page detection on the multifd
thread, so allow ramblock_set_file_bmap_atomic() to also clear the
bits.
Signed-off-by: Fabiano Rosas <farosas@suse.de>
---
migration/multifd.c | 2 +-
migration/ram.c | 8 ++++++--
migration/ram.h | 3 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/migration/multifd.c b/migration/multifd.c
index d4a44da559..6b8a78e4ca 100644
--- a/migration/multifd.c
+++ b/migration/multifd.c
@@ -115,7 +115,7 @@ static void multifd_set_file_bitmap(MultiFDSendParams *p)
assert(pages->block);
for (int i = 0; i < p->pages->num; i++) {
- ramblock_set_file_bmap_atomic(pages->block, pages->offset[i]);
+ ramblock_set_file_bmap_atomic(pages->block, pages->offset[i], true);
}
}
diff --git a/migration/ram.c b/migration/ram.c
index 003c28e133..f4abc47bbf 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3150,9 +3150,13 @@ static void ram_save_file_bmap(QEMUFile *f)
}
}
-void ramblock_set_file_bmap_atomic(RAMBlock *block, ram_addr_t offset)
+void ramblock_set_file_bmap_atomic(RAMBlock *block, ram_addr_t offset, bool set)
{
- set_bit_atomic(offset >> TARGET_PAGE_BITS, block->file_bmap);
+ if (set) {
+ set_bit_atomic(offset >> TARGET_PAGE_BITS, block->file_bmap);
+ } else {
+ clear_bit_atomic(offset >> TARGET_PAGE_BITS, block->file_bmap);
+ }
}
/**
diff --git a/migration/ram.h b/migration/ram.h
index b9ac0da587..08feecaf51 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -75,7 +75,8 @@ bool ram_dirty_bitmap_reload(MigrationState *s, RAMBlock *rb, Error **errp);
bool ramblock_page_is_discarded(RAMBlock *rb, ram_addr_t start);
void postcopy_preempt_shutdown_file(MigrationState *s);
void *postcopy_preempt_thread(void *opaque);
-void ramblock_set_file_bmap_atomic(RAMBlock *block, ram_addr_t offset);
+void ramblock_set_file_bmap_atomic(RAMBlock *block, ram_addr_t offset,
+ bool set);
/* ram cache */
int colo_init_ram_cache(void);
--
2.30.2
next prev parent reply other threads:[~2024-03-11 18:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-11 18:00 [PATCH v6 0/7] Introduce multifd zero page checking Hao Xiang
2024-03-11 18:00 ` [PATCH v6 1/7] migration/multifd: Allow zero pages in file migration Hao Xiang
2024-03-11 18:00 ` Hao Xiang [this message]
2024-03-11 18:00 ` [PATCH v6 3/7] migration/multifd: Add new migration option zero-page-detection Hao Xiang
2024-03-11 18:00 ` [PATCH v6 4/7] migration/multifd: Implement zero page transmission on the multifd thread Hao Xiang
2024-03-11 20:18 ` Fabiano Rosas
2024-03-11 18:00 ` [PATCH v6 5/7] migration/multifd: Implement ram_save_target_page_multifd to handle multifd version of MigrationOps::ram_save_target_page Hao Xiang
2024-03-11 18:00 ` [PATCH v6 6/7] migration/multifd: Enable multifd zero page checking by default Hao Xiang
2024-03-11 20:41 ` Peter Xu
2024-03-11 20:44 ` Fabiano Rosas
2024-03-11 18:00 ` [PATCH v6 7/7] migration/multifd: Add new migration test cases for legacy zero page checking Hao Xiang
2024-03-11 20:59 ` Peter Xu
2024-03-11 20:43 ` [PATCH v6 0/7] Introduce multifd " 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=20240311180015.3359271-3-hao.xiang@linux.dev \
--to=hao.xiang@linux.dev \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=jdenemar@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).