[libvirt] [PATCH v3 04/10] block/dirty-bitmap: change semantics of enabled predicate

[Vladimir Sementsov-Ogievskiy]

23.02.2019 3:06, John Snow wrote:
> Currently, the enabled predicate means something like:
> "the QAPI status of the bitmap is ACTIVE."
> After this patch, it should mean exclusively:
> "This bitmap is recording guest writes, and is allowed to do so."
> 
> In many places, this is how this predicate was already used.
> Internal usages of the bitmap QPI can call user_locked to find out if
> the bitmap is in use by an operation.
> 
> To accommodate this, modify the create_successor routine to now
> explicitly disable the parent bitmap at creation time.
> 
> 
> Justifications:
> 
> 1. bdrv_dirty_bitmap_status suffers no change from the lack of
>     1:1 parity with the new predicates because of the order in which
>     the predicates are checked. This is now only for compatibility.
> 
> 2. bdrv_set_dirty() is unchanged: pre-patch, it was skipping bitmaps that were
>     disabled or had a successor, while post-patch it is only skipping bitmaps
>     that are disabled. To accommodate this, create_successor now ensures that
>     any bitmap with a successor is explicitly disabled.
> 
> 3. qcow2_store_persistent_dirty_bitmaps: No functional change. This function
>     cares only about the literal enabled bit, and makes no effort to check if
>     the bitmap is in-use or not. After this patch there are still no ways to
>     produce an enabled bitmap with a successor.
> 
> 4. block_dirty_bitmap_enable_prepare
>     block_dirty_bitmap_disable_prepare
>     init_dirty_bitmap_migration
>     nbd_export_new
> 
>     These functions care about the literal enabled bit,
>     and already check user_locked separately.
> 
> Signed-off-by: John Snow<jsnow at redhat.com>

Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov at virtuozzo.com>

-- 
Best regards,
Vladimir