On 12/12/2012 06:46 AM, Paolo Bonzini wrote: > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > block-migration.c | 5 +++-- > block.c | 17 ++++++++++------- > block.h | 5 +---- > block/mirror.c | 14 ++++---------- > qapi-schema.json | 4 +++- > 5 files changed, 21 insertions(+), 24 deletions(-) >
> @@ -4218,16 +4220,17 @@ void *qemu_blockalign(BlockDriverState *bs, size_t
> size)
> return qemu_memalign((bs && bs->buffer_alignment) ? bs->buffer_alignment
> : 512, size);
> }
>
> -void bdrv_set_dirty_tracking(BlockDriverState *bs, int enable)
> +void bdrv_set_dirty_tracking(BlockDriverState *bs, int granularity)
> {
> int64_t bitmap_size;
>
> - if (enable) {
> - if (!bs->dirty_bitmap) {
> - bitmap_size = (bdrv_getlength(bs) >> BDRV_SECTOR_BITS);
> - bs->dirty_bitmap = hbitmap_alloc(bitmap_size,
> -
> BDRV_LOG_SECTORS_PER_DIRTY_CHUNK);
> - }
> + assert((granularity & (granularity - 1)) == 0);
> +
> + if (granularity) {
> + granularity >>= BDRV_SECTOR_BITS;
Given that granularity is specified in bytes, does it make sense for a
user to want a granularity of 4G? I guess another way of wording this
question is: Are you sure 'int granularity' is the right type?
> +++ b/qapi-schema.json
> @@ -667,10 +667,12 @@
> #
> # @count: number of dirty bytes according to the dirty bitmap
> #
> +# @granularity: granularity of the dirty bitmap in bytes
Mention that this field was added in 1.4.
> +#
> # Since: 1.3
> ##
> { 'type': 'BlockDirtyInfo',
> - 'data': {'count': 'int'} }
> + 'data': {'count': 'int', 'granularity': 'int'} }
>
> ##
> # @BlockInfo:
>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
