bwlp/qemu.git/block/dirty-bitmap.c, branch spice_video_codecs

block: simplify handling of try to merge different sized bitmaps

2022-06-24T15:07:06+00:00

We have too much logic to simply check that bitmaps are of the same size. Let's just define that hbitmap_merge() and bdrv_dirty_bitmap_merge_internal() require their argument bitmaps be of same size, this simplifies things. Let's look through the callers: For backup_init_bcs_bitmap() we already assert that merge can't fail. In bdrv_reclaim_dirty_bitmap_locked() we gracefully handle the error that can't happen: successor always has same size as its parent, drop this logic. In bdrv_merge_dirty_bitmap() we already has assertion and separate check. Make the check explicit and improve error message. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Nikita Lapshin Reviewed-by: Kevin Wolf Message-Id: <20220517111206.23585-4-v.sementsov-og@mail.ru> Signed-off-by: Kevin Wolf

block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()

2022-03-07T08:33:30+00:00

Add a convenient function similar with bdrv_block_status() to get status of dirty bitmap. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Hanna Reitz Message-Id: <20220303194349.2304213-9-vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz

block/dirty-bitmap: bdrv_merge_dirty_bitmap(): add return value

2022-03-07T08:33:30+00:00

That simplifies handling failure in existing code and in further new usage of bdrv_merge_dirty_bitmap(). Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Hanna Reitz Message-Id: <20220303194349.2304213-3-vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz

IO_CODE and IO_OR_GS_CODE for block_int I/O API

2022-03-04T17:18:25+00:00

Mark all I/O functions with IO_CODE, and all "I/O OR GS" with IO_OR_GS_CODE. Signed-off-by: Emanuele Giuseppe Esposito Message-Id: <20220303151616.325444-14-eesposit@redhat.com> Signed-off-by: Kevin Wolf

assertions for block_int global state API

2022-03-04T17:18:25+00:00

Signed-off-by: Emanuele Giuseppe Esposito Message-Id: <20220303151616.325444-13-eesposit@redhat.com> Signed-off-by: Kevin Wolf

IO_CODE and IO_OR_GS_CODE for block I/O API

2022-03-04T17:18:25+00:00

Mark all I/O functions with IO_CODE, and all "I/O OR GS" with IO_OR_GS_CODE. Signed-off-by: Emanuele Giuseppe Esposito Message-Id: <20220303151616.325444-6-eesposit@redhat.com> Signed-off-by: Kevin Wolf

iotests: Improve and rename test 291 to qemu-img-bitmap

2021-07-21T19:14:41+00:00

Enhance the test to demonstrate existing less-than-stellar behavior of qemu-img with a qcow2 image containing an inconsistent bitmap: we don't diagnose the problem until after copying the entire image (a potentially long time), and when we do diagnose the failure, we still end up leaving an empty bitmap in the destination. This mess will be cleaned up in the next patch. While at it, rename the test now that we support useful iotest names, and fix a missing newline in the error message thus exposed. Signed-off-by: Eric Blake Message-Id: <20210709153951.2801666-2-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Nir Soffer

block: remove dirty bitmaps 'status' field

2021-03-18T09:22:55+00:00

The same information is available via the 'recording' and 'busy' fields. Reviewed-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Daniel P. Berrangé

qcow2-bitmap: make bytes_covered_by_bitmap_cluster() public

2021-03-08T13:56:54+00:00

Rename bytes_covered_by_bitmap_cluster() to bdrv_dirty_bitmap_serialization_coverage() and make it public. It is needed as we are going to share it with bitmap loading in parallels format. Signed-off-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Eric Blake Reviewed-by: Denis V. Lunev Message-Id: <20210224104707.88430-2-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf

qapi: Use QAPI_LIST_APPEND in trivial cases

2021-01-28T07:08:45+00:00

The easiest spots to use QAPI_LIST_APPEND are where we already have an obvious pointer to the tail of a list. While at it, consistently use the variable name 'tail' for that purpose. Signed-off-by: Eric Blake Reviewed-by: Vladimir Sementsov-Ogievskiy Reviewed-by: Markus Armbruster Message-Id: <20210113221013.390592-5-eblake@redhat.com> Signed-off-by: Markus Armbruster