[{"id":1765285,"web_url":"http://patchwork.ozlabs.org/comment/1765285/","msgid":"<20170908122254.GG3283@localhost.localdomain>","list_archive_url":null,"date":"2017-09-08T12:22:54","subject":"Re: [Qemu-devel] [PATCH v6 05/18] dirty-bitmap: Change\n\tbdrv_dirty_bitmap_size() to report bytes","submitter":{"id":2714,"url":"http://patchwork.ozlabs.org/api/people/2714/","name":"Kevin Wolf","email":"kwolf@redhat.com"},"content":"Am 30.08.2017 um 23:05 hat Eric Blake geschrieben:\n> We are still using an internal hbitmap that tracks a size in sectors,\n> with the granularity scaled down accordingly, because it lets us\n> use a shortcut for our iterators which are currently sector-based.\n> But there's no reason we can't track the dirty bitmap size in bytes,\n> since it is (mostly) an internal-only variable (remember, the size\n> is how many bytes are covered by the bitmap, not how many bytes the\n> bitmap occupies). Furthermore, we're already reporting bytes for\n> bdrv_dirty_bitmap_granularity(); mixing bytes and sectors in our\n> return values is a recipe for confusion. A later cleanup will\n> convert dirty bitmap internals to be entirely byte-based,\n> eliminating the intermediate sector rounding added here; and\n> technically, since bdrv_getlength() already rounds up to sectors,\n> our use of DIV_ROUND_UP is more for theoretical completeness than\n> for any actual rounding.\n> \n> The only external caller in qcow2-bitmap.c is temporarily more verbose\n> (because it is still using sector-based math), but will later be\n> switched to track progress by bytes instead of sectors.\n> \n> Use is_power_of_2() while at it, instead of open-coding that, and\n> add an assertion where bdrv_getlength() should not fail.\n> \n> Signed-off-by: Eric Blake \n> Reviewed-by: John Snow \n\nI think I would have preferred to change the unit of\nBdrvDirtyBitmap.size in one patch and the unit of the return value of\nbdrv_dirty_bitmap_size() in another one to keep review a bit easier.\n\n> block/dirty-bitmap.c | 26 +++++++++++++++-----------\n> block/qcow2-bitmap.c | 14 ++++++++------\n> 2 files changed, 23 insertions(+), 17 deletions(-)\n> \n> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c\n> index 42a55e4a4b..e65ec4f7ec 100644\n> --- a/block/dirty-bitmap.c\n> +++ b/block/dirty-bitmap.c\n> @@ -1,7 +1,7 @@\n> /*\n> * Block Dirty Bitmap\n> *\n> - * Copyright (c) 2016 Red Hat. Inc\n> + * Copyright (c) 2016-2017 Red Hat. Inc\n> *\n> * Permission is hereby granted, free of charge, to any person obtaining a copy\n> * of this software and associated documentation files (the \"Software\"), to deal\n> @@ -42,7 +42,7 @@ struct BdrvDirtyBitmap {\n> HBitmap *meta; /* Meta dirty bitmap */\n> BdrvDirtyBitmap *successor; /* Anonymous child; implies frozen status */\n> char *name; /* Optional non-empty unique ID */\n> - int64_t size; /* Size of the bitmap (Number of sectors) */\n> + int64_t size; /* Size of the bitmap, in bytes */\n> bool disabled; /* Bitmap is disabled. It ignores all writes to\n> the device */\n> int active_iterators; /* How many iterators are active */\n> @@ -115,17 +115,14 @@ BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs,\n> {\n> int64_t bitmap_size;\n> BdrvDirtyBitmap *bitmap;\n> - uint32_t sector_granularity;\n> \n> - assert((granularity & (granularity - 1)) == 0);\n> + assert(is_power_of_2(granularity) && granularity >= BDRV_SECTOR_SIZE);\n> \n> if (name && bdrv_find_dirty_bitmap(bs, name)) {\n> error_setg(errp, \"Bitmap already exists: %s\", name);\n> return NULL;\n> }\n> - sector_granularity = granularity >> BDRV_SECTOR_BITS;\n> - assert(sector_granularity);\n> - bitmap_size = bdrv_nb_sectors(bs);\n> + bitmap_size = bdrv_getlength(bs);\n> if (bitmap_size < 0) {\n> error_setg_errno(errp, -bitmap_size, \"could not get length of device\");\n> errno = -bitmap_size;\n> @@ -133,7 +130,12 @@ BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs,\n> }\n> bitmap = g_new0(BdrvDirtyBitmap, 1);\n> bitmap->mutex = &bs->dirty_bitmap_mutex;\n> - bitmap->bitmap = hbitmap_alloc(bitmap_size, ctz32(sector_granularity));\n> + /*\n> + * TODO - let hbitmap track full granularity. For now, it is tracking\n> + * only sector granularity, as a shortcut for our iterators.\n> + */\n> + bitmap->bitmap = hbitmap_alloc(DIV_ROUND_UP(bitmap_size, BDRV_SECTOR_SIZE),\n> + ctz32(granularity) - BDRV_SECTOR_BITS);\n> bitmap->size = bitmap_size;\n> bitmap->name = g_strdup(name);\n> bitmap->disabled = false;\n> @@ -305,13 +307,14 @@ BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap(BlockDriverState *bs,\n> void bdrv_dirty_bitmap_truncate(BlockDriverState *bs)\n> {\n> BdrvDirtyBitmap *bitmap;\n> - uint64_t size = bdrv_nb_sectors(bs);\n> + int64_t size = bdrv_getlength(bs);\n> \n> + assert(size >= 0);\n\nHow can you assert that there will never be an error? Even if it's\ncorrect (I don't know whether you can have dirty bitmaps on devices that\ndon't use the cached value), this needs at least a comment.\n\nThe rest looks okay.\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=208.118.235.17; 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=kwolf@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [208.118.235.17])\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 3xpc1Q17l8z9tYV\n\tfor ;\n\tFri, 8 Sep 2017 22:23:33 +1000 (AEST)","from localhost ([::1]:45213 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqIJn-0000Un-Rj\n\tfor incoming@patchwork.ozlabs.org; Fri, 08 Sep 2017 08:23:31 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:42771)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqIJT-0000TN-74\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 08:23:12 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqIJS-0004A6-0K\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 08:23:11 -0400","from mx1.redhat.com ([209.132.183.28]:38776)\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 1dqIJM-000449-0x; Fri, 08 Sep 2017 08:23:04 -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 DCD667E421;\n\tFri, 8 Sep 2017 12:23:02 +0000 (UTC)","from localhost.localdomain (ovpn-116-113.ams2.redhat.com\n\t[10.36.116.113])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id EDB12600C2;\n\tFri, 8 Sep 2017 12:22:55 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com DCD667E421","Date":"Fri, 8 Sep 2017 14:22:54 +0200","From":"Kevin Wolf ","To":"Eric Blake ","Message-ID":"<20170908122254.GG3283@localhost.localdomain>","References":"<20170830210542.2153-1-eblake@redhat.com>\n\t<20170830210542.2153-6-eblake@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170830210542.2153-6-eblake@redhat.com>","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.27]);\n\tFri, 08 Sep 2017 12:23:03 +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 v6 05/18] dirty-bitmap: Change\n\tbdrv_dirty_bitmap_size() to report bytes","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, Fam Zheng ,\n\tqemu-block@nongnu.org, qemu-devel@nongnu.org,\n\tMax Reitz , jsnow@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1765396,"web_url":"http://patchwork.ozlabs.org/comment/1765396/","msgid":"","list_archive_url":null,"date":"2017-09-08T14:04:15","subject":"Re: [Qemu-devel] [PATCH v6 05/18] dirty-bitmap: Change\n\tbdrv_dirty_bitmap_size() to report bytes","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/08/2017 07:22 AM, Kevin Wolf wrote:\n> Am 30.08.2017 um 23:05 hat Eric Blake geschrieben:\n>> We are still using an internal hbitmap that tracks a size in sectors,\n>> with the granularity scaled down accordingly, because it lets us\n>> use a shortcut for our iterators which are currently sector-based.\n>> But there's no reason we can't track the dirty bitmap size in bytes,\n>> since it is (mostly) an internal-only variable (remember, the size\n>> is how many bytes are covered by the bitmap, not how many bytes the\n>> bitmap occupies). Furthermore, we're already reporting bytes for\n>> bdrv_dirty_bitmap_granularity(); mixing bytes and sectors in our\n>> return values is a recipe for confusion. A later cleanup will\n>> convert dirty bitmap internals to be entirely byte-based,\n>> eliminating the intermediate sector rounding added here; and\n>> technically, since bdrv_getlength() already rounds up to sectors,\n>> our use of DIV_ROUND_UP is more for theoretical completeness than\n>> for any actual rounding.\n>>\n>> The only external caller in qcow2-bitmap.c is temporarily more verbose\n>> (because it is still using sector-based math), but will later be\n>> switched to track progress by bytes instead of sectors.\n>>\n>> Use is_power_of_2() while at it, instead of open-coding that, and\n>> add an assertion where bdrv_getlength() should not fail.\n>>\n>> Signed-off-by: Eric Blake \n>> Reviewed-by: John Snow \n> \n> I think I would have preferred to change the unit of\n> BdrvDirtyBitmap.size in one patch and the unit of the return value of\n> bdrv_dirty_bitmap_size() in another one to keep review a bit easier.\n\nI can split on respin, if there's still enough reason for a respin.\n\n>> @@ -305,13 +307,14 @@ BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap(BlockDriverState *bs,\n>> void bdrv_dirty_bitmap_truncate(BlockDriverState *bs)\n>> {\n>> BdrvDirtyBitmap *bitmap;\n>> - uint64_t size = bdrv_nb_sectors(bs);\n>> + int64_t size = bdrv_getlength(bs);\n>>\n>> + assert(size >= 0);\n> \n> How can you assert that there will never be an error? Even if it's\n> correct (I don't know whether you can have dirty bitmaps on devices that\n> don't use the cached value), this needs at least a comment.\n\nThe old code wasn't checking for errors; if an error occurs, we have no\nway to report it. So I indeed need to audit whether all callers have a\ncached length at this point in time (it can't fail), or else change\nbdrv_dirty_bitmap_truncate() to be able to fail (pass failure along) and\nupdate all callers. This may indeed be reason for a respin, depending\non what I find.","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-mx10.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx10.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 3xpfHF5yrHz9s7G\n\tfor ;\n\tSat, 9 Sep 2017 00:05:45 +1000 (AEST)","from localhost ([::1]:45605 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqJuh-0007XK-VX\n\tfor incoming@patchwork.ozlabs.org; Fri, 08 Sep 2017 10:05:44 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:44999)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqJtj-00074I-DD\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 10:04:49 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqJte-0004ug-Nf\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 10:04:43 -0400","from mx1.redhat.com ([209.132.183.28]:52348)\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 1dqJtQ-0004d6-46; Fri, 08 Sep 2017 10:04:24 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\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 17D105AFC8;\n\tFri, 8 Sep 2017 14:04:23 +0000 (UTC)","from [10.10.120.228] (ovpn-120-228.rdu2.redhat.com [10.10.120.228])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id D1E4960605;\n\tFri, 8 Sep 2017 14:04:16 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 17D105AFC8","To":"Kevin Wolf ","References":"<20170830210542.2153-1-eblake@redhat.com>\n\t<20170830210542.2153-6-eblake@redhat.com>\n\t<20170908122254.GG3283@localhost.localdomain>","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"","Date":"Fri, 8 Sep 2017 09:04:15 -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":"<20170908122254.GG3283@localhost.localdomain>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"cKkUkAJGQdBoQceJPXeEVJPcGLmNGMiq0\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tFri, 08 Sep 2017 14:04:23 +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 v6 05/18] dirty-bitmap: Change\n\tbdrv_dirty_bitmap_size() to report bytes","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, Fam Zheng ,\n\tqemu-block@nongnu.org, qemu-devel@nongnu.org,\n\tMax Reitz , jsnow@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1767298,"web_url":"http://patchwork.ozlabs.org/comment/1767298/","msgid":"","list_archive_url":null,"date":"2017-09-12T19:35:31","subject":"Re: [Qemu-devel] [PATCH v6 05/18] dirty-bitmap: Change\n\tbdrv_dirty_bitmap_size() to report bytes","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/08/2017 09:04 AM, Eric Blake wrote:\n\n>>> void bdrv_dirty_bitmap_truncate(BlockDriverState *bs)\n>>> {\n>>> BdrvDirtyBitmap *bitmap;\n>>> - uint64_t size = bdrv_nb_sectors(bs);\n>>> + int64_t size = bdrv_getlength(bs);\n>>>\n>>> + assert(size >= 0);\n>>\n>> How can you assert that there will never be an error? Even if it's\n>> correct (I don't know whether you can have dirty bitmaps on devices that\n>> don't use the cached value), this needs at least a comment.\n> \n> The old code wasn't checking for errors; if an error occurs, we have no\n> way to report it. So I indeed need to audit whether all callers have a\n> cached length at this point in time (it can't fail), or else change\n> bdrv_dirty_bitmap_truncate() to be able to fail (pass failure along) and\n> update all callers. This may indeed be reason for a respin, depending\n> on what I find.\n\nVerdict - it can indeed fail; bdrv_truncate() was blindly calling the\ndirty bitmap resize even after a failed refresh_total_sectors(), which\ncould then resize the dirty bitmap to -1. At least bdrv_truncate()\nitself still failed, but it's cleaner to fail up front rather than get\ninternal state even more botched in the meantime, so fixing that will be\na separate patch in v7. Sadly, the failure is probably more\ntheoretical, and I did not quickly see an easy way to write an iotests\nto expose it (which has been the case with a lot of our recent\nbdrv_nb_sectors/bdrv_getlength failure cleanup patches).","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-mx10.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx10.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 3xsFQs1xqVz9sNV\n\tfor ;\n\tWed, 13 Sep 2017 05:36:19 +1000 (AEST)","from localhost ([::1]:38285 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1drqym-0001BQ-1r\n\tfor incoming@patchwork.ozlabs.org; Tue, 12 Sep 2017 15:36:16 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:48632)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1drqyL-00017O-NG\n\tfor qemu-devel@nongnu.org; Tue, 12 Sep 2017 15:35:50 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1drqyH-0008Po-Nf\n\tfor qemu-devel@nongnu.org; Tue, 12 Sep 2017 15:35:49 -0400","from mx1.redhat.com ([209.132.183.28]:59998)\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 1drqyC-0008LA-Pv; Tue, 12 Sep 2017 15:35:41 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\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 419D75F739;\n\tTue, 12 Sep 2017 19:35:39 +0000 (UTC)","from [10.10.120.44] (ovpn-120-44.rdu2.redhat.com [10.10.120.44])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 3AE6617DF3;\n\tTue, 12 Sep 2017 19:35:32 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 419D75F739","To":"Kevin Wolf ","References":"<20170830210542.2153-1-eblake@redhat.com>\n\t<20170830210542.2153-6-eblake@redhat.com>\n\t<20170908122254.GG3283@localhost.localdomain>\n\t","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"","Date":"Tue, 12 Sep 2017 14:35:31 -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":"","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"wvEudaeX6x1kNDXe0epOJJMr0kXklMHnL\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tTue, 12 Sep 2017 19:35:39 +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 v6 05/18] dirty-bitmap: Change\n\tbdrv_dirty_bitmap_size() to report bytes","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, Fam Zheng ,\n\tqemu-block@nongnu.org, qemu-devel@nongnu.org,\n\tMax Reitz , jsnow@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]