[{"id":1770999,"web_url":"http://patchwork.ozlabs.org/comment/1770999/","msgid":"<20170919124424.GD3789@localhost.localdomain>","list_archive_url":null,"date":"2017-09-19T12:44:24","subject":"Re: [Qemu-devel] [PATCH v8 18/20] qcow2: Switch store_bitmap_data()\n\tto byte-based iteration","submitter":{"id":2714,"url":"http://patchwork.ozlabs.org/api/people/2714/","name":"Kevin Wolf","email":"kwolf@redhat.com"},"content":"Am 18.09.2017 um 20:58 hat Eric Blake geschrieben:\n> Now that we have adjusted the majority of the calls this function\n> makes to be byte-based, it is easier to read the code if it makes\n> passes over the image using bytes rather than sectors.\n> \n> Signed-off-by: Eric Blake \n> Reviewed-by: John Snow \n> Reviewed-by: Vladimir Sementsov-Ogievskiy \n> \n> ---\n> v7: rebase to earlier change, make rounding of offset obvious (no semantic\n> change, so R-b kept) [Kevin]\n> v5-v6: no change\n> v4: new patch\n> ---\n> block/qcow2-bitmap.c | 26 +++++++++++---------------\n> 1 file changed, 11 insertions(+), 15 deletions(-)\n> \n> diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c\n> index 692ce0de88..302fffd6e1 100644\n> --- a/block/qcow2-bitmap.c\n> +++ b/block/qcow2-bitmap.c\n> @@ -1072,10 +1072,9 @@ static uint64_t *store_bitmap_data(BlockDriverState *bs,\n> {\n> int ret;\n> BDRVQcow2State *s = bs->opaque;\n> - int64_t sector;\n> - uint64_t limit, sbc;\n> + int64_t offset;\n> + uint64_t limit;\n> uint64_t bm_size = bdrv_dirty_bitmap_size(bitmap);\n> - uint64_t bm_sectors = DIV_ROUND_UP(bm_size, BDRV_SECTOR_SIZE);\n> const char *bm_name = bdrv_dirty_bitmap_name(bitmap);\n> uint8_t *buf = NULL;\n> BdrvDirtyBitmapIter *dbi;\n> @@ -1100,18 +1099,17 @@ static uint64_t *store_bitmap_data(BlockDriverState *bs,\n> dbi = bdrv_dirty_iter_new(bitmap);\n> buf = g_malloc(s->cluster_size);\n> limit = bytes_covered_by_bitmap_cluster(s, bitmap);\n> - sbc = limit >> BDRV_SECTOR_BITS;\n> assert(DIV_ROUND_UP(bm_size, limit) == tb_size);\n> \n> - while ((sector = bdrv_dirty_iter_next(dbi) >> BDRV_SECTOR_BITS) >= 0) {\n> - uint64_t cluster = sector / sbc;\n> + while ((offset = bdrv_dirty_iter_next(dbi)) >= 0) {\n> + uint64_t cluster = offset / limit;\n> uint64_t end, write_size;\n> int64_t off;\n> \n> - sector = cluster * sbc;\n> - end = MIN(bm_sectors, sector + sbc);\n> - write_size = bdrv_dirty_bitmap_serialization_size(bitmap,\n> - sector * BDRV_SECTOR_SIZE, (end - sector) * BDRV_SECTOR_SIZE);\n> + offset = QEMU_ALIGN_DOWN(offset, limit);\n\nWith the question that I asked in v6, apart from changing the spelling\nto be more explicit, I actually hoped that you would explain why\naligning down is the right thing to do.\n\nIt looks plausible to me that we can do this in correct code because we\ndon't support granularities < 512 bytes (a qemu restriction that is\nwritten down as a note in the qcow2 spec).\n\nThe part that I'm missing yet is why we need to do it. The bitmap\ngranularity is also the granularity of bdrv_dirty_iter_next(), so isn't\noffset already aligned and we could even assert that instead of aligning\ndown? (As long we enforce our restriction, which we seem to do in\nbitmap_list_load().)\n\n> + end = MIN(bm_size, offset + limit);\n> + write_size = bdrv_dirty_bitmap_serialization_size(bitmap, offset,\n> + end - offset);\n> assert(write_size <= s->cluster_size);\n> \n> off = qcow2_alloc_clusters(bs, s->cluster_size);\n\nKevin","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=kwolf@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxNs36zMqz9sBZ\n\tfor ;\n\tTue, 19 Sep 2017 23:24:55 +1000 (AEST)","from localhost ([::1]:42856 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duIWE-0007n0-2s\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 09:24:54 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:41673)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duHtN-0007z5-1u\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 08:44:46 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duHtG-00077K-Td\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 08:44:45 -0400","from mx1.redhat.com ([209.132.183.28]:59852)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duHtC-00074P-21; Tue, 19 Sep 2017 08:44:34 -0400","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 0B8C481DFF;\n\tTue, 19 Sep 2017 12:44:33 +0000 (UTC)","from localhost.localdomain (ovpn-116-117.ams2.redhat.com\n\t[10.36.116.117])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 180845D983;\n\tTue, 19 Sep 2017 12:44:25 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 0B8C481DFF","Date":"Tue, 19 Sep 2017 14:44:24 +0200","From":"Kevin Wolf ","To":"Eric Blake ","Message-ID":"<20170919124424.GD3789@localhost.localdomain>","References":"<20170918185819.5984-1-eblake@redhat.com>\n\t<20170918185819.5984-19-eblake@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170918185819.5984-19-eblake@redhat.com>","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.25]);\n\tTue, 19 Sep 2017 12:44:33 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v8 18/20] qcow2: Switch store_bitmap_data()\n\tto byte-based iteration","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"vsementsov@virtuozzo.com, jsnow@redhat.com, qemu-devel@nongnu.org,\n\tqemu-block@nongnu.org, Max Reitz ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771326,"web_url":"http://patchwork.ozlabs.org/comment/1771326/","msgid":"","list_archive_url":null,"date":"2017-09-19T19:42:59","subject":"Re: [Qemu-devel] [PATCH v8 18/20] qcow2: Switch store_bitmap_data()\n\tto byte-based iteration","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/19/2017 07:44 AM, Kevin Wolf wrote:\n> Am 18.09.2017 um 20:58 hat Eric Blake geschrieben:\n>> Now that we have adjusted the majority of the calls this function\n>> makes to be byte-based, it is easier to read the code if it makes\n>> passes over the image using bytes rather than sectors.\n>>\n>> Signed-off-by: Eric Blake \n>> Reviewed-by: John Snow \n>> Reviewed-by: Vladimir Sementsov-Ogievskiy \n\n>> @@ -1100,18 +1099,17 @@ static uint64_t *store_bitmap_data(BlockDriverState *bs,\n>> dbi = bdrv_dirty_iter_new(bitmap);\n>> buf = g_malloc(s->cluster_size);\n>> limit = bytes_covered_by_bitmap_cluster(s, bitmap);\n\nLimit is huge. For ease of math, let's consider an image with 512-byte\nclusters, and an explicit bitmap granularity of 512 bytes. One cluster\n(512 bytes, or 4k bits) of the bitmap covers 4k multiples of the\ngranularity, or 2M of image; and the minimum serialization alignment of\n64 bits covers 32k bytes of image. bytes_covered_by_bitmap_cluster()\ncomputes granularity (512 bytes per bit), limit (2M bytes per cluster of\nbits), and checks that 2M is indeed aligned to\nbdrv_dirty_bitmap_serialization_align() (which is 32k).\n\nNext, an image with default 64k clusters and a default bitmap\ngranularity of 64k bytes; one cluster (64k bytes, or 512k bits) now\ncovers 512k multiples of the granularity, or 32G of image size.\n\nHowever...\n\n>> - sbc = limit >> BDRV_SECTOR_BITS;\n>> assert(DIV_ROUND_UP(bm_size, limit) == tb_size);\n>>\n>> - while ((sector = bdrv_dirty_iter_next(dbi) >> BDRV_SECTOR_BITS) >= 0) {\n>> - uint64_t cluster = sector / sbc;\n>> + while ((offset = bdrv_dirty_iter_next(dbi)) >= 0) {\n>> + uint64_t cluster = offset / limit;\n\nbdrv_dirty_iter_next() returns the next dirty bit (which is not\nnecessarily the first bit in the cluster). For the purposes of\nserialization, we want to serialize the entire cluster in one go, even\nthough we will be serializing 0 bits up until the first dirty bit. So\noffset at this point may be unaligned,\n\n>> uint64_t end, write_size;\n>> int64_t off;\n>>\n>> - sector = cluster * sbc;\n>> - end = MIN(bm_sectors, sector + sbc);\n>> - write_size = bdrv_dirty_bitmap_serialization_size(bitmap,\n>> - sector * BDRV_SECTOR_SIZE, (end - sector) * BDRV_SECTOR_SIZE);\n>> + offset = QEMU_ALIGN_DOWN(offset, limit);\n\nand we round it down to the start of the cluster that we will actually\nbe serializing.\n\n> \n> With the question that I asked in v6, apart from changing the spelling\n> to be more explicit, I actually hoped that you would explain why\n> aligning down is the right thing to do.\n> \n> It looks plausible to me that we can do this in correct code because we\n> don't support granularities < 512 bytes (a qemu restriction that is\n> written down as a note in the qcow2 spec).\n\nIt's not granularities < 512 that we have to worry about, but dirty bits\nwith an offset < 4M (because we are serializing an entire cluster of\nbitmap data, where the first dirty offset is not necessarily aligned to\nthat large).\n\n> \n> The part that I'm missing yet is why we need to do it. The bitmap\n> granularity is also the granularity of bdrv_dirty_iter_next(), so isn't\n> offset already aligned and we could even assert that instead of aligning\n> down? (As long we enforce our restriction, which we seem to do in\n> bitmap_list_load().)\n\nSadly, a quick:\n\ndiff --git i/block/qcow2-bitmap.c w/block/qcow2-bitmap.c\nindex 302fffd6e1..160f3b99f9 100644\n--- i/block/qcow2-bitmap.c\n+++ w/block/qcow2-bitmap.c\n@@ -1106,6 +1106,7 @@ static uint64_t\n*store_bitmap_data(BlockDriverState *bs,\n uint64_t end, write_size;\n int64_t off;\n\n+ assert(QEMU_IS_ALIGNED(offset, limit));\n offset = QEMU_ALIGN_DOWN(offset, limit);\n end = MIN(bm_size, offset + limit);\n write_size = bdrv_dirty_bitmap_serialization_size(bitmap, offset,\n\ndoes NOT fail iotests 165, which appears to be the only test that\nactually hammers on qcow2 bitmaps (changing it to an 'assert(false)'\nonly shows an effect on 165) - which means our test is NOT exercising\nall possible alignments. And it's python-based, with lame output, which\nmakes debugging it painful. But never fear, for v9 I will improve the\ntest to actually affect the bitmap at a point that would fail with my\ntemporary assertion in place, and thus proving that we DO need to align\ndown. Note that test 165 is testing only a 1G image, but I just showed\nthat 64k clusters with 64k granularity covers up to 32G of image space\nin one cluster of the bitmap, so the test is only covering one cluster\nof serialization in the first place, and as written, the test is\ndirtying byte 0, which explains why it happens to get an offset aligned\nto limit, even though that is not a valid assertion.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=eblake@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxYGC4Nw1z9rxm\n\tfor ;\n\tWed, 20 Sep 2017 05:43:45 +1000 (AEST)","from localhost ([::1]:45080 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duOQo-0000Ha-Jk\n\tfor incoming@patchwork.ozlabs.org; Tue, 19 Sep 2017 15:43:42 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:49925)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duOQQ-0000Ef-PF\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 15:43:20 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duOQP-0004lP-Cq\n\tfor qemu-devel@nongnu.org; Tue, 19 Sep 2017 15:43:18 -0400","from mx1.redhat.com ([209.132.183.28]:10588)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duOQJ-0004gf-J6; Tue, 19 Sep 2017 15:43:11 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 6C75C78EB1;\n\tTue, 19 Sep 2017 19:43:10 +0000 (UTC)","from [10.10.124.97] (ovpn-124-97.rdu2.redhat.com [10.10.124.97])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 4E6C85FCA4;\n\tTue, 19 Sep 2017 19:42:59 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 6C75C78EB1","To":"Kevin Wolf ","References":"<20170918185819.5984-1-eblake@redhat.com>\n\t<20170918185819.5984-19-eblake@redhat.com>\n\t<20170919124424.GD3789@localhost.localdomain>","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"","Date":"Tue, 19 Sep 2017 14:42:59 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170919124424.GD3789@localhost.localdomain>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"BmclKvP40ErUksRlPB6upBwRVdPCrfQU1\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.27]);\n\tTue, 19 Sep 2017 19:43:10 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","X-Content-Filtered-By":"Mailman/MimeDel 2.1.21","Subject":"Re: [Qemu-devel] [PATCH v8 18/20] qcow2: Switch store_bitmap_data()\n\tto byte-based iteration","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"vsementsov@virtuozzo.com, jsnow@redhat.com, qemu-devel@nongnu.org,\n\tqemu-block@nongnu.org, Max Reitz ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1771612,"web_url":"http://patchwork.ozlabs.org/comment/1771612/","msgid":"<20170920062244.GA4730@localhost.localdomain>","list_archive_url":null,"date":"2017-09-20T06:22:44","subject":"Re: [Qemu-devel] [PATCH v8 18/20] qcow2: Switch store_bitmap_data()\n\tto byte-based iteration","submitter":{"id":2714,"url":"http://patchwork.ozlabs.org/api/people/2714/","name":"Kevin Wolf","email":"kwolf@redhat.com"},"content":"Am 19.09.2017 um 21:42 hat Eric Blake geschrieben:\n> However...\n> \n> >> - sbc = limit >> BDRV_SECTOR_BITS;\n> >> assert(DIV_ROUND_UP(bm_size, limit) == tb_size);\n> >>\n> >> - while ((sector = bdrv_dirty_iter_next(dbi) >> BDRV_SECTOR_BITS) >= 0) {\n> >> - uint64_t cluster = sector / sbc;\n> >> + while ((offset = bdrv_dirty_iter_next(dbi)) >= 0) {\n> >> + uint64_t cluster = offset / limit;\n> \n> bdrv_dirty_iter_next() returns the next dirty bit (which is not\n> necessarily the first bit in the cluster). For the purposes of\n> serialization, we want to serialize the entire cluster in one go, even\n> though we will be serializing 0 bits up until the first dirty bit. So\n> offset at this point may be unaligned,\n\nOk, this is the part that I was missing. It makes a lot more sense now.\n\nAlso, I think 'cluster' meaning bitmap clusters and not qcow2 clusters\nhere confused me a bit.\n\n> > The part that I'm missing yet is why we need to do it. The bitmap\n> > granularity is also the granularity of bdrv_dirty_iter_next(), so isn't\n> > offset already aligned and we could even assert that instead of aligning\n> > down? (As long we enforce our restriction, which we seem to do in\n> > bitmap_list_load().)\n> \n> Sadly, a quick:\n> [...]\n> does NOT fail iotests 165, which appears to be the only test that\n> actually hammers on qcow2 bitmaps (changing it to an 'assert(false)'\n> only shows an effect on 165) - which means our test is NOT exercising\n> all possible alignments. And it's python-based, with lame output, which\n> makes debugging it painful. But never fear, for v9 I will improve the\n> test to actually affect the bitmap at a point that would fail with my\n> temporary assertion in place, and thus proving that we DO need to align\n> down. Note that test 165 is testing only a 1G image, but I just showed\n> that 64k clusters with 64k granularity covers up to 32G of image space\n> in one cluster of the bitmap, so the test is only covering one cluster\n> of serialization in the first place, and as written, the test is\n> dirtying byte 0, which explains why it happens to get an offset aligned\n> to limit, even though that is not a valid assertion.\n\nMore tests are always welcome and a good argument for getting a series\nmerged. :-)\n\nKevin","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=kwolf@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xxqVl1Zrcz9sPs\n\tfor ;\n\tWed, 20 Sep 2017 16:25:35 +1000 (AEST)","from localhost ([::1]:46953 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1duYRw-00077s-MS\n\tfor incoming@patchwork.ozlabs.org; Wed, 20 Sep 2017 02:25:32 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36509)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1duYPR-0005aG-Ua\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:22:59 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1duYPQ-0007AT-PY\n\tfor qemu-devel@nongnu.org; Wed, 20 Sep 2017 02:22:57 -0400","from mx1.redhat.com ([209.132.183.28]:43394)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1duYPJ-0006JP-Ts; Wed, 20 Sep 2017 02:22:50 -0400","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id C612486647;\n\tWed, 20 Sep 2017 06:22:48 +0000 (UTC)","from localhost.localdomain (ovpn-116-76.ams2.redhat.com\n\t[10.36.116.76])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 8F448600CA;\n\tWed, 20 Sep 2017 06:22:45 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com C612486647","Date":"Wed, 20 Sep 2017 08:22:44 +0200","From":"Kevin Wolf ","To":"Eric Blake ","Message-ID":"<20170920062244.GA4730@localhost.localdomain>","References":"<20170918185819.5984-1-eblake@redhat.com>\n\t<20170918185819.5984-19-eblake@redhat.com>\n\t<20170919124424.GD3789@localhost.localdomain>\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"y0ulUmNC+osPPQO6\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.8.3 (2017-05-23)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]);\n\tWed, 20 Sep 2017 06:22:48 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v8 18/20] qcow2: Switch store_bitmap_data()\n\tto byte-based iteration","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"vsementsov@virtuozzo.com, jsnow@redhat.com, qemu-devel@nongnu.org,\n\tqemu-block@nongnu.org, Max Reitz ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]