On Thu, Sep 15, 2022 at 07:49:57PM +0100, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > Since we already have bitmap_mutex to protect either the dirty bitmap or
> > the clear log bitmap, we don't need atomic operations to set/clear/test on
> > the clear log bitmap. Switching all ops from atomic to non-atomic
> > versions, meanwhile touch up the comments to show which lock is in charge.
> >
> > Introduced non-atomic version of bitmap_test_and_clear_atomic(), mostly the
> > same as the atomic version but simplified a few places, e.g. dropped the
> > "old_bits" variable, and also the explicit memory barriers.
> >
> > Signed-off-by: Peter Xu <pet...@redhat.com>
>
> Can you update the comment in ramblock.h above clear_bmap to say it's
> always updated under that lock.
I'll squash below into the same patch:
---8<---
diff --git a/include/exec/ramblock.h b/include/exec/ramblock.h
index 6cbedf9e0c..adc03df59c 100644
--- a/include/exec/ramblock.h
+++ b/include/exec/ramblock.h
@@ -53,6 +53,9 @@ struct RAMBlock {
* and split clearing of dirty bitmap on the remote node (e.g.,
* KVM). The bitmap will be set only when doing global sync.
*
+ * It is only used during src side of ram migration, and it is
+ * protected by the global ram_state.bitmap_mutex.
+ *
* NOTE: this bitmap is different comparing to the other bitmaps
* in that one bit can represent multiple guest pages (which is
* decided by the `clear_bmap_shift' variable below). On
---8<---
>
> Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
Thanks,
--
Peter Xu
