qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: kwolf@redhat.com, peter.maydell@linaro.org, quintela@redhat.com,
	qemu-devel@nongnu.org, dgilbert@redhat.com,
	vsementsov@parallels.com, den@openvz.org, amit.shah@redhat.com,
	pbonzini@redhat.com, jsnow@redhat.com
Subject: Re: [Qemu-devel] [PATCH 01/12] hbitmap: serialization
Date: Thu, 20 Aug 2015 07:53:26 -0700	[thread overview]
Message-ID: <20150820145326.GC21642@stefanha-thinkpad> (raw)
In-Reply-To: <1438939964-12584-2-git-send-email-vsementsov@virtuozzo.com>

[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]

On Fri, Aug 07, 2015 at 12:32:33PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> +/**
> + * hbitmap_serialize_part
> + * @hb: HBitmap to oprate on.

s/oprate/operate/

> + * @buf: Buffer to store serialized bitmap.
> + * @start: First bit to store.
> + * @count: Number of bits to store.
> + *
> + * Stores HBitmap data corresponding to given region. The format of saved data
> + * is linear sequence of bits, so it can be used by hbitmap_deserialize_part
> + * independently of endianness and size of HBitmap level array elements

These functions *are* dependent of HBitmap level array element size.

They always assign full array elements (unsigned long).  If count <
BITS_PER_LONG at some point before the end, the bitmap will be corrupt
because leading bits will be zeroed when the next
hbitmap_deserialize_part() call is made!

> + */
> +void hbitmap_serialize_part(const HBitmap *hb, uint8_t *buf,
> +                            uint64_t start, uint64_t count);
> +
> +/**
> + * hbitmap_deserialize_part
> + * @hb: HBitmap to operate on.
> + * @buf: Buffer to restore bitmap data from.
> + * @start: First bit to restore.
> + * @count: Number of bits to restore.
> + *
> + * Retores HBitmap data corresponding to given region. The format is the same

s/Retores/Restores/

> + * as for hbitmap_serialize_part.
> + *
> + * ! The bitmap becomes inconsistent after this operation.
> + * hbitmap_serialize_finish should be called before using the bitmap after
> + * data restoring.
> + */
> +void hbitmap_deserialize_part(HBitmap *hb, uint8_t *buf,
> +                              uint64_t start, uint64_t count);
> +
> +/**
> + * hbitmap_deserialize_zeroes
> + * @hb: HBitmap to operate on.
> + * @start: First bit to restore.
> + * @count: Number of bits to restore.
> + *
> + * Same as hbitmap_serialize_part, but fills the bitmap with zeroes.
> + */
> +void hbitmap_deserialize_zeroes(HBitmap *hb, uint64_t start, uint64_t count);
> +
> +/**
> + * hbitmap_deserialize_finish
> + * @hb: HBitmap to operate on.
> + *
> + * Repair HBitmap after calling hbitmap_deserialize_data. Actually, all HBitmap
> + * layers are restored here.
> + */
> +void hbitmap_deserialize_finish(HBitmap *hb);
> +
> +/**
>   * hbitmap_free:
>   * @hb: HBitmap to operate on.
>   *
> diff --git a/util/hbitmap.c b/util/hbitmap.c
> index 50b888f..c7c21fe 100644
> --- a/util/hbitmap.c
> +++ b/util/hbitmap.c
> @@ -378,6 +378,104 @@ bool hbitmap_get(const HBitmap *hb, uint64_t item)
>      return (hb->levels[HBITMAP_LEVELS - 1][pos >> BITS_PER_LEVEL] & bit) != 0;
>  }
>  
> +uint64_t hbitmap_data_size(const HBitmap *hb, uint64_t count)
> +{
> +    uint64_t size, gran;
> +
> +    if (count == 0) {
> +        return 0;
> +    }
> +
> +    gran = 1ll << hb->granularity;
> +    size = (((gran + count - 2) >> hb->granularity) >> BITS_PER_LEVEL) + 1;
> +
> +    return size * sizeof(unsigned long);
> +}
> +
> +void hbitmap_serialize_part(const HBitmap *hb, uint8_t *buf,
> +                            uint64_t start, uint64_t count)
> +{
> +    uint64_t i;
> +    uint64_t last = start + count - 1;
> +    unsigned long *out = (unsigned long *)buf;

I'm not sure if we care but this can lead to unaligned stores if buf
isn't aligned to sizeof(unsigned long).  Unaligned stores are best
avoided:
https://www.linux-mips.org/wiki/Alignment

If you replace out[i - start] = ... with a memcpy() call then the
alignment problem is solved.  If you are worried that all these memcpy()
calls are slow, check the compiler output since gcc probably optimizes
away the memcpy().

> +
> +    if (count == 0) {
> +        return;
> +    }
> +
> +    start = (start >> hb->granularity) >> BITS_PER_LEVEL;
> +    last = (last >> hb->granularity) >> BITS_PER_LEVEL;
> +    count = last - start + 1;
> +
> +    for (i = start; i <= last; ++i) {
> +        unsigned long el = hb->levels[HBITMAP_LEVELS - 1][i];
> +        out[i - start] =
> +            (BITS_PER_LONG == 32 ? cpu_to_le32(el) : cpu_to_le64(el));
> +    }
> +}
> +
> +void hbitmap_deserialize_part(HBitmap *hb, uint8_t *buf,
> +                              uint64_t start, uint64_t count)
> +{
> +    uint64_t i;
> +    uint64_t last = start + count - 1;
> +    unsigned long *in = (unsigned long *)buf;

Same here.

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-08-20 14:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07  9:32 [Qemu-devel] [PATCH v6 00/12] Dirty bitmaps migration Vladimir Sementsov-Ogievskiy
2015-08-07  9:32 ` [Qemu-devel] [PATCH 01/12] hbitmap: serialization Vladimir Sementsov-Ogievskiy
2015-08-20 14:53   ` Stefan Hajnoczi [this message]
2015-08-07  9:32 ` [Qemu-devel] [PATCH 02/12] block: BdrvDirtyBitmap serialization interface Vladimir Sementsov-Ogievskiy
2015-08-07  9:32 ` [Qemu-devel] [PATCH 03/12] block: tiny refactoring: minimize hbitmap_(set/reset) usage Vladimir Sementsov-Ogievskiy
2015-08-07  9:32 ` [Qemu-devel] [PATCH 04/12] block: add meta bitmaps Vladimir Sementsov-Ogievskiy
2015-08-07  9:32 ` [Qemu-devel] [PATCH 05/12] block: add bdrv_next_dirty_bitmap() Vladimir Sementsov-Ogievskiy
2015-08-07  9:32 ` [Qemu-devel] [PATCH 06/12] qapi: add dirty-bitmaps migration capability Vladimir Sementsov-Ogievskiy
2015-09-15 16:27   ` Eric Blake
2015-08-07  9:32 ` [Qemu-devel] [PATCH 07/12] migration/qemu-file: add qemu_put_counted_string() Vladimir Sementsov-Ogievskiy
2015-09-11  0:02   ` John Snow
2015-08-07  9:32 ` [Qemu-devel] [PATCH 08/12] migration: add migration/block-dirty-bitmap.c Vladimir Sementsov-Ogievskiy
2015-09-11  0:10   ` John Snow
2015-08-07  9:32 ` [Qemu-devel] [PATCH 09/12] iotests: maintain several vms in test Vladimir Sementsov-Ogievskiy
2015-08-07  9:32 ` [Qemu-devel] [PATCH 10/12] iotests: add add_incoming_migration to VM class Vladimir Sementsov-Ogievskiy
2015-08-07  9:32 ` [Qemu-devel] [PATCH 11/12] qapi: add md5 checksum of last dirty bitmap level to query-block Vladimir Sementsov-Ogievskiy
2015-09-15 16:29   ` Eric Blake
2015-09-15 19:44     ` John Snow
2015-09-16  5:22       ` Markus Armbruster
2015-08-07  9:32 ` [Qemu-devel] [PATCH 12/12] iotests: add dirty bitmap migration test Vladimir Sementsov-Ogievskiy
2015-08-07 10:10 ` [Qemu-devel] [PATCH v6 00/12] Dirty bitmaps migration Vladimir Sementsov-Ogievskiy
2015-09-11  0:11 ` John Snow
  -- strict thread matches above, loose matches on Subject: below --
2015-05-13 15:29 [Qemu-devel] [PATCH v5 " Vladimir Sementsov-Ogievskiy
2015-05-13 15:29 ` [Qemu-devel] [PATCH 01/12] hbitmap: serialization Vladimir Sementsov-Ogievskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150820145326.GC21642@stefanha-thinkpad \
    --to=stefanha@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=den@openvz.org \
    --cc=dgilbert@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=vsementsov@parallels.com \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).