block: per caller dirty bitmap
Previously a BlockDriverState has only one dirty bitmap, so only one caller (e.g. a block job) can keep track of writing. This changes the dirty bitmap to a list and creates a BdrvDirtyBitmap for each caller, the lifecycle is managed with these new functions: bdrv_create_dirty_bitmap bdrv_release_dirty_bitmap Where BdrvDirtyBitmap is a linked list wrapper structure of HBitmap. In place of bdrv_set_dirty_tracking, a BdrvDirtyBitmap pointer argument is added to these functions, since each caller has its own dirty bitmap: bdrv_get_dirty bdrv_dirty_iter_init bdrv_get_dirty_count bdrv_set_dirty and bdrv_reset_dirty prototypes are unchanged but will internally walk the list of all dirty bitmaps and set them one by one. Signed-off-by:Fam Zheng <famz@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com>
Showing
- block-migration.c 16 additions, 6 deletionsblock-migration.c
- block.c 49 additions, 34 deletionsblock.c
- block/mirror.c 13 additions, 10 deletionsblock/mirror.c
- block/qapi.c 0 additions, 8 deletionsblock/qapi.c
- include/block/block.h 7 additions, 4 deletionsinclude/block/block.h
- include/block/block_int.h 1 addition, 1 deletioninclude/block/block_int.h
Loading
Please register or sign in to comment