* Re: [Qemu-devel] [PATCH v6 04/10] hbitmap: Add hbitmap_copy
@ 2014-11-17 12:48 Vladimir Sementsov-Ogievskiy
0 siblings, 0 replies; 3+ messages in thread
From: Vladimir Sementsov-Ogievskiy @ 2014-11-17 12:48 UTC (permalink / raw)
To: famz
Cc: Kevin Wolf, Benoit Canet, John Snow, Markus Armbruster,
qemu-devel, Max Reitz, Stefan Hajnoczi, Jd, Paolo Bonzini,
Luiz Capitulino
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
> +
> +HBitmap *hbitmap_copy(const HBitmap *bitmap)
> +{
> + int i;
> + int64_t size;
> + HBitmap *hb = g_memdup(bitmap, sizeof(struct HBitmap));
> +
> + size = bitmap->size;
> + for (i = HBITMAP_LEVELS; i-- > 0; ) {
> + size = MAX((size + BITS_PER_LONG - 1) >> BITS_PER_LEVEL, 1);
> + hb->levels[i] = g_memdup(bitmap->levels[i],
> + size * sizeof(unsigned long));
> + }
> +
> + return hb;
> +}
"(size + BITS_PER_LONG - 1) >> BITS_PER_LEVEL" - will be zero iff size == 0. Is it really possible in qemu? If not, we doesn't need MAX(..., 1).
There is similar construction in older "hbitmap_alloc" function.
--
Best regards,
Vladimir
[-- Attachment #2: Type: text/html, Size: 1611 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* [Qemu-devel] [PATCH v6 00/10] block: Incremental backup series
@ 2014-10-30 3:22 Fam Zheng
2014-10-30 3:22 ` [Qemu-devel] [PATCH v6 04/10] hbitmap: Add hbitmap_copy Fam Zheng
0 siblings, 1 reply; 3+ messages in thread
From: Fam Zheng @ 2014-10-30 3:22 UTC (permalink / raw)
To: qemu-devel
Cc: Kevin Wolf, Benoit Canet, Vladimir Sementsov-Ogievskij,
Markus Armbruster, Max Reitz, John Snow, Stefan Hajnoczi, Jd,
Paolo Bonzini, Luiz Capitulino
v6: Rebased v4 of the series on top of qemu.git. (skipping v5 since it was used
by me as a private sending, for those who received it, the code is the same
:)
This is the in memory part of the incremental backup feature.
With the added commands, we can create a bitmap on a block backend, from which
point of time all the writes are tracked by the bitmap, marking sectors as
dirty. Later, we call drive-backup and pass the bitmap to it, to do an
incremental backup.
See the last patch which adds some tests for this use case.
Fam
Fam Zheng (10):
qapi: Add optional field "name" to block dirty bitmap
qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove
block: Introduce bdrv_dirty_bitmap_granularity()
hbitmap: Add hbitmap_copy
block: Add bdrv_copy_dirty_bitmap and bdrv_reset_dirty_bitmap
qmp: Add block-dirty-bitmap-enable and block-dirty-bitmap-disable
qmp: Add support of "dirty-bitmap" sync mode for drive-backup
qapi: Add transaction support to
block-dirty-bitmap-{add,enable,disable}
qmp: Add dirty bitmap 'enabled' field in query-block
qemu-iotests: Add tests for drive-backup sync=dirty-bitmap
block-migration.c | 2 +-
block.c | 82 ++++++++++++++++-
block/backup.c | 54 +++++++++++-
block/mirror.c | 6 +-
blockdev.c | 198 +++++++++++++++++++++++++++++++++++++++++-
hmp.c | 4 +-
include/block/block.h | 15 +++-
include/block/block_int.h | 4 +
include/qemu/hbitmap.h | 8 ++
qapi-schema.json | 5 +-
qapi/block-core.json | 120 +++++++++++++++++++++++--
qmp-commands.hx | 66 +++++++++++++-
tests/qemu-iotests/056 | 33 ++++++-
tests/qemu-iotests/056.out | 4 +-
tests/qemu-iotests/iotests.py | 8 ++
util/hbitmap.c | 16 ++++
16 files changed, 603 insertions(+), 22 deletions(-)
--
1.9.3
^ permalink raw reply [flat|nested] 3+ messages in thread* [Qemu-devel] [PATCH v6 04/10] hbitmap: Add hbitmap_copy
2014-10-30 3:22 [Qemu-devel] [PATCH v6 00/10] block: Incremental backup series Fam Zheng
@ 2014-10-30 3:22 ` Fam Zheng
2014-11-04 9:58 ` Max Reitz
0 siblings, 1 reply; 3+ messages in thread
From: Fam Zheng @ 2014-10-30 3:22 UTC (permalink / raw)
To: qemu-devel
Cc: Kevin Wolf, Benoit Canet, Vladimir Sementsov-Ogievskij,
Markus Armbruster, Max Reitz, John Snow, Stefan Hajnoczi, Jd,
Paolo Bonzini, Luiz Capitulino
This makes a deep copy of an HBitmap.
Signed-off-by: Fam Zheng <famz@redhat.com>
---
include/qemu/hbitmap.h | 8 ++++++++
util/hbitmap.c | 16 ++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
index 550d7ce..b645cfc 100644
--- a/include/qemu/hbitmap.h
+++ b/include/qemu/hbitmap.h
@@ -65,6 +65,14 @@ struct HBitmapIter {
HBitmap *hbitmap_alloc(uint64_t size, int granularity);
/**
+ * hbitmap_copy:
+ * @bitmap: The original bitmap to copy.
+ *
+ * Copy a HBitmap.
+ */
+HBitmap *hbitmap_copy(const HBitmap *bitmap);
+
+/**
* hbitmap_empty:
* @hb: HBitmap to operate on.
*
diff --git a/util/hbitmap.c b/util/hbitmap.c
index b3060e6..78d449e 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -395,3 +395,19 @@ HBitmap *hbitmap_alloc(uint64_t size, int granularity)
hb->levels[0][0] |= 1UL << (BITS_PER_LONG - 1);
return hb;
}
+
+HBitmap *hbitmap_copy(const HBitmap *bitmap)
+{
+ int i;
+ int64_t size;
+ HBitmap *hb = g_memdup(bitmap, sizeof(struct HBitmap));
+
+ size = bitmap->size;
+ for (i = HBITMAP_LEVELS; i-- > 0; ) {
+ size = MAX((size + BITS_PER_LONG - 1) >> BITS_PER_LEVEL, 1);
+ hb->levels[i] = g_memdup(bitmap->levels[i],
+ size * sizeof(unsigned long));
+ }
+
+ return hb;
+}
--
1.9.3
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [Qemu-devel] [PATCH v6 04/10] hbitmap: Add hbitmap_copy
2014-10-30 3:22 ` [Qemu-devel] [PATCH v6 04/10] hbitmap: Add hbitmap_copy Fam Zheng
@ 2014-11-04 9:58 ` Max Reitz
0 siblings, 0 replies; 3+ messages in thread
From: Max Reitz @ 2014-11-04 9:58 UTC (permalink / raw)
To: Fam Zheng, qemu-devel
Cc: Kevin Wolf, Benoit Canet, Vladimir Sementsov-Ogievskij,
Markus Armbruster, Luiz Capitulino, John Snow, Stefan Hajnoczi,
Jd, Paolo Bonzini
On 2014-10-30 at 04:22, Fam Zheng wrote:
> This makes a deep copy of an HBitmap.
>
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
> include/qemu/hbitmap.h | 8 ++++++++
> util/hbitmap.c | 16 ++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
> index 550d7ce..b645cfc 100644
> --- a/include/qemu/hbitmap.h
> +++ b/include/qemu/hbitmap.h
> @@ -65,6 +65,14 @@ struct HBitmapIter {
> HBitmap *hbitmap_alloc(uint64_t size, int granularity);
>
> /**
> + * hbitmap_copy:
> + * @bitmap: The original bitmap to copy.
> + *
> + * Copy a HBitmap.
> + */
> +HBitmap *hbitmap_copy(const HBitmap *bitmap);
> +
> +/**
> * hbitmap_empty:
> * @hb: HBitmap to operate on.
> *
> diff --git a/util/hbitmap.c b/util/hbitmap.c
> index b3060e6..78d449e 100644
> --- a/util/hbitmap.c
> +++ b/util/hbitmap.c
> @@ -395,3 +395,19 @@ HBitmap *hbitmap_alloc(uint64_t size, int granularity)
> hb->levels[0][0] |= 1UL << (BITS_PER_LONG - 1);
> return hb;
> }
> +
> +HBitmap *hbitmap_copy(const HBitmap *bitmap)
> +{
> + int i;
> + int64_t size;
Why not uint64_t, like HBitmap::size? Not that it matters in practice, I
hope.
> + HBitmap *hb = g_memdup(bitmap, sizeof(struct HBitmap));
"struct" can be omitted.
> +
> + size = bitmap->size;
> + for (i = HBITMAP_LEVELS; i-- > 0; ) {
Urgh... I'd prefer "for (i = HBITMAP_LEVELS - 1; i >= 0; i--)" though
yours is correct and shorter.
> + size = MAX((size + BITS_PER_LONG - 1) >> BITS_PER_LEVEL, 1);
> + hb->levels[i] = g_memdup(bitmap->levels[i],
> + size * sizeof(unsigned long));
> + }
> +
> + return hb;
> +}
With or without any of the changes:
Reviewed-by: Max Reitz <mreitz@redhat.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-11-17 12:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-17 12:48 [Qemu-devel] [PATCH v6 04/10] hbitmap: Add hbitmap_copy Vladimir Sementsov-Ogievskiy
-- strict thread matches above, loose matches on Subject: below --
2014-10-30 3:22 [Qemu-devel] [PATCH v6 00/10] block: Incremental backup series Fam Zheng
2014-10-30 3:22 ` [Qemu-devel] [PATCH v6 04/10] hbitmap: Add hbitmap_copy Fam Zheng
2014-11-04 9:58 ` Max Reitz
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).