[{"id":1768102,"web_url":"http://patchwork.ozlabs.org/comment/1768102/","msgid":"","list_archive_url":null,"date":"2017-09-13T19:26:19","subject":"Re: [Qemu-devel] [PATCH v4 21/23] block: Align block status requests","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/13/2017 11:03 AM, Eric Blake wrote:\n> Any device that has request_alignment greater than 512 should be\n> unable to report status at a finer granularity; it may also be\n> simpler for such devices to be guaranteed that the block layer\n> has rounded things out to the granularity boundary (the way the\n> block layer already rounds all other I/O out). Besides, getting\n> the code correct for super-sector alignment also benefits us\n> for the fact that our public interface now has byte granularity,\n> even though none of our drivers have byte-level callbacks.\n> \n> Add an assertion in blkdebug that proves that the block layer\n> never requests status of unaligned sections, similar to what it\n> does on other requests (while still keeping the generic helper\n> in place for when future patches add a throttle driver). Note\n> that iotest 177 already covers this (it would fail if you use\n> just the blkdebug.c hunk without the io.c changes). Meanwhile,\n> we can drop assertions in callers that no longer have to pass\n> in sector-aligned addresses.\n\nBummer - 'git bisect' says this patch causes iotests 190 to hang. I'm\ninvestigating root cause, but I'll have to post a fixup once I figure it\nout.","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-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.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 3xssB5413Nz9ryv\n\tfor ;\n\tThu, 14 Sep 2017 05:27:23 +1000 (AEST)","from localhost ([::1]:44271 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dsDJg-0006nN-6g\n\tfor incoming@patchwork.ozlabs.org; Wed, 13 Sep 2017 15:27:20 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:33135)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dsDIx-0006jH-8m\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 15:26:36 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dsDIw-0004t2-6S\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 15:26:35 -0400","from mx1.redhat.com ([209.132.183.28]:43474)\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 1dsDIq-0004op-HP; Wed, 13 Sep 2017 15:26:28 -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 6A7EC4E4D4;\n\tWed, 13 Sep 2017 19:26:27 +0000 (UTC)","from [10.10.120.201] (ovpn-120-201.rdu2.redhat.com [10.10.120.201])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id A237F60C8A;\n\tWed, 13 Sep 2017 19:26:20 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 6A7EC4E4D4","To":"qemu-devel@nongnu.org","References":"<20170913160333.23622-1-eblake@redhat.com>\n\t<20170913160333.23622-22-eblake@redhat.com>","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"","Date":"Wed, 13 Sep 2017 14:26:19 -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":"<20170913160333.23622-22-eblake@redhat.com>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"vU6dL22Hkrx27xjxT4Eq44kkiPxbVKJtE\"","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.38]);\n\tWed, 13 Sep 2017 19:26:27 +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 v4 21/23] block: Align block status requests","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":"kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org,\n\tMax Reitz ,\n\tStefan Hajnoczi , jsnow@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1768154,"web_url":"http://patchwork.ozlabs.org/comment/1768154/","msgid":"<3643e882-0a39-99f2-24ac-8e9ac502e9f7@redhat.com>","list_archive_url":null,"date":"2017-09-13T20:36:21","subject":"Re: [Qemu-devel] [PATCH v4 21/23] block: Align block status requests","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/13/2017 02:26 PM, Eric Blake wrote:\n> On 09/13/2017 11:03 AM, Eric Blake wrote:\n>> Any device that has request_alignment greater than 512 should be\n>> unable to report status at a finer granularity; it may also be\n>> simpler for such devices to be guaranteed that the block layer\n>> has rounded things out to the granularity boundary (the way the\n>> block layer already rounds all other I/O out). Besides, getting\n>> the code correct for super-sector alignment also benefits us\n>> for the fact that our public interface now has byte granularity,\n>> even though none of our drivers have byte-level callbacks.\n>>\n>> Add an assertion in blkdebug that proves that the block layer\n>> never requests status of unaligned sections, similar to what it\n>> does on other requests (while still keeping the generic helper\n>> in place for when future patches add a throttle driver). Note\n>> that iotest 177 already covers this (it would fail if you use\n>> just the blkdebug.c hunk without the io.c changes). Meanwhile,\n>> we can drop assertions in callers that no longer have to pass\n>> in sector-aligned addresses.\n> \n> Bummer - 'git bisect' says this patch causes iotests 190 to hang. I'm\n> investigating root cause, but I'll have to post a fixup once I figure it\n> out.\n\nFound it:\n\n> + /* Round out to request_alignment boundaries */\n> + align = MAX(bs->bl.request_alignment, BDRV_SECTOR_SIZE);\n> + aligned_offset = QEMU_ALIGN_DOWN(offset, align);\n> + aligned_bytes = ROUND_UP(offset + bytes, align) - aligned_offset;\n\nROUND_UP(64-bit, 32-bit) has a subtle bug: it truncates the operation at\n32 bits, instead of producing a 64-bit result. Using QEMU_ROUND_UP\ninstead does NOT have the bug.\n\nThat's a ticking time bomb, so I'll patch ROUND_UP() directly as a\npre-requisite, then reply to the cover letter with a Based-on tag.","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 3xstkR5xPjz9sMN\n\tfor ;\n\tThu, 14 Sep 2017 06:37:02 +1000 (AEST)","from localhost ([::1]:44568 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dsEP5-0003zW-P6\n\tfor incoming@patchwork.ozlabs.org; Wed, 13 Sep 2017 16:36:59 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:53704)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dsEOi-0003xM-K5\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 16:36:37 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dsEOh-0002tJ-Jb\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 16:36:36 -0400","from mx1.redhat.com ([209.132.183.28]:43180)\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 1dsEOc-0002py-1U; Wed, 13 Sep 2017 16:36:30 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\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 015D87E422;\n\tWed, 13 Sep 2017 20:36:29 +0000 (UTC)","from [10.10.120.201] (ovpn-120-201.rdu2.redhat.com [10.10.120.201])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id C500351919;\n\tWed, 13 Sep 2017 20:36:21 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 015D87E422","To":"qemu-devel@nongnu.org","References":"<20170913160333.23622-1-eblake@redhat.com>\n\t<20170913160333.23622-22-eblake@redhat.com>\n\t","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"<3643e882-0a39-99f2-24ac-8e9ac502e9f7@redhat.com>","Date":"Wed, 13 Sep 2017 15:36:21 -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=\"mt0jCBh61VPiwvKolUSsTB6aiPTOttGp1\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.27]);\n\tWed, 13 Sep 2017 20:36:29 +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 v4 21/23] block: Align block status requests","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":"kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org,\n\tMax Reitz ,\n\tStefan Hajnoczi , jsnow@redhat.com","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1778581,"web_url":"http://patchwork.ozlabs.org/comment/1778581/","msgid":"<2d443ce7-b533-cd70-0e60-1bba52ac6d69@redhat.com>","list_archive_url":null,"date":"2017-10-02T20:24:51","subject":"Re: [Qemu-devel] [PATCH v4 21/23] block: Align block status requests","submitter":{"id":64343,"url":"http://patchwork.ozlabs.org/api/people/64343/","name":"John Snow","email":"jsnow@redhat.com"},"content":"On 09/13/2017 12:03 PM, Eric Blake wrote:\n> Any device that has request_alignment greater than 512 should be\n> unable to report status at a finer granularity; it may also be\n> simpler for such devices to be guaranteed that the block layer\n> has rounded things out to the granularity boundary (the way the\n> block layer already rounds all other I/O out). Besides, getting\n> the code correct for super-sector alignment also benefits us\n> for the fact that our public interface now has byte granularity,\n> even though none of our drivers have byte-level callbacks.\n> \n> Add an assertion in blkdebug that proves that the block layer\n> never requests status of unaligned sections, similar to what it\n> does on other requests (while still keeping the generic helper\n> in place for when future patches add a throttle driver). Note\n> that iotest 177 already covers this (it would fail if you use\n> just the blkdebug.c hunk without the io.c changes). Meanwhile,\n> we can drop assertions in callers that no longer have to pass\n> in sector-aligned addresses.\n> \n> There is a mid-function scope added for 'int count', for a\n> couple of reasons: first, an upcoming patch will add an 'if'\n> statement that checks whether a driver has an old- or new-style\n> callback, and can conveniently use the same scope for less\n> indentation churn at that time. Second, since we are trying\n> to get rid of sector-based computations, wrapping things in\n> a scope makes it easier to group and see what will be deleted\n> in a final cleanup patch once all drivers have been converted\n> to the new-style callback.\n> \n> Signed-off-by: Eric Blake \n> \n> ---\n> v3: tweak commit message [Fam], rebase to context conflicts, ensure\n> we don't exceed 32-bit limit, drop R-b\n> v2: new patch\n> ---\n> include/block/block_int.h | 3 ++-\n> block/io.c | 55 +++++++++++++++++++++++++++++++----------------\n> block/blkdebug.c | 13 ++++++++++-\n> 3 files changed, 51 insertions(+), 20 deletions(-)\n> \n> diff --git a/include/block/block_int.h b/include/block/block_int.h\n> index 7f71c585a0..b1ceffba78 100644\n> --- a/include/block/block_int.h\n> +++ b/include/block/block_int.h\n> @@ -207,7 +207,8 @@ struct BlockDriver {\n> * according to the current layer, and should not set\n> * BDRV_BLOCK_ALLOCATED, but may set BDRV_BLOCK_RAW. See block.h\n> * for the meaning of _DATA, _ZERO, and _OFFSET_VALID. The block\n> - * layer guarantees non-NULL pnum and file.\n> + * layer guarantees input aligned to request_alignment, as well as\n> + * non-NULL pnum and file.\n> */\n> int64_t coroutine_fn (*bdrv_co_get_block_status)(BlockDriverState *bs,\n> int64_t sector_num, int nb_sectors, int *pnum,\n> diff --git a/block/io.c b/block/io.c\n> index ea63d19480..c78201b8eb 100644\n> --- a/block/io.c\n> +++ b/block/io.c\n> @@ -1773,7 +1773,8 @@ static int64_t coroutine_fn bdrv_co_block_status(BlockDriverState *bs,\n> int64_t n; /* bytes */\n> int64_t ret, ret2;\n> BlockDriverState *local_file = NULL;\n> - int count; /* sectors */\n> + int64_t aligned_offset, aligned_bytes;\n> + uint32_t align;\n> \n> assert(pnum);\n> total_size = bdrv_getlength(bs);\n> @@ -1815,28 +1816,45 @@ static int64_t coroutine_fn bdrv_co_block_status(BlockDriverState *bs,\n> }\n> \n> bdrv_inc_in_flight(bs);\n> - /*\n> - * TODO: Rather than require aligned offsets, we could instead\n> - * round to the driver's request_alignment here, then touch up\n> - * count afterwards back to the caller's expectations.\n> - */\n> - assert(QEMU_IS_ALIGNED(offset | bytes, BDRV_SECTOR_SIZE));\n> - bytes = MIN(bytes, BDRV_REQUEST_MAX_BYTES);\n> - ret = bs->drv->bdrv_co_get_block_status(bs, offset >> BDRV_SECTOR_BITS,\n> - bytes >> BDRV_SECTOR_BITS, &count,\n> - &local_file);\n> - if (ret < 0) {\n> - *pnum = 0;\n> - goto out;\n> +\n> + /* Round out to request_alignment boundaries */\n> + align = MAX(bs->bl.request_alignment, BDRV_SECTOR_SIZE);\n\nThere's something funny to me about an alignment request getting itself\naligned...\n\n> + aligned_offset = QEMU_ALIGN_DOWN(offset, align);\n> + aligned_bytes = ROUND_UP(offset + bytes, align) - aligned_offset;\n> +\n> + {\n> + int count; /* sectors */\n> +\n> + assert(QEMU_IS_ALIGNED(aligned_offset | aligned_bytes,\n> + BDRV_SECTOR_SIZE));\n> + ret = bs->drv->bdrv_co_get_block_status(\n> + bs, aligned_offset >> BDRV_SECTOR_BITS,\n> + MIN(INT_MAX, aligned_bytes) >> BDRV_SECTOR_BITS, &count,\n\nI guess under the belief that INT_MAX will be strictly less than\nBDRV_REQUEST_MAX_BYTES, or some other reason I'm missing for the change?\n\n> + &local_file);\n> + if (ret < 0) {\n> + *pnum = 0;\n> + goto out;\n> + }\n> + *pnum = count * BDRV_SECTOR_SIZE;\n\nIs it asking for trouble to be updating pnum here before we undo our\nalignment corrections? For readability reasons and preventing an\naccidental context-based oopsy-daisy.\n\n> + }\n> +\n> + /* Clamp pnum and ret to original request */\n> + assert(QEMU_IS_ALIGNED(*pnum, align));\n\nOh, do we guarantee this? I guess we do..\n\n> + *pnum -= offset - aligned_offset;\n\ncan pnum prior to adjustment ever be less than offset - aligned_offset?\ni.e., can this underflow?\n\n(Can we fail to actually inquire about the range the caller was\ninterested in by aligning down too much and observing a difference in\nallocation status between the alignment pre-range and the actual range?)\n\n> + if (aligned_offset >> BDRV_SECTOR_BITS != offset >> BDRV_SECTOR_BITS &&\n> + ret & BDRV_BLOCK_OFFSET_VALID) {\n> + ret += QEMU_ALIGN_DOWN(offset - aligned_offset, BDRV_SECTOR_SIZE);\n> + }\n\nAlright, and if the starting sectors are different (Wait, why is it\nsectors now instead of the requested alignment? Is this safe for all\nformats?) we adjust the return value forward a little bit to match the\ndifference.\n\n> + if (*pnum > bytes) {\n> + *pnum = bytes;\n> }\n\nAssuming this clamps the aligned_bytes range down to the bytes range, in\ncase it's contiguous beyond what the caller asked for.\n\n> - *pnum = count * BDRV_SECTOR_SIZE;\n> \n> if (ret & BDRV_BLOCK_RAW) {\n> assert(ret & BDRV_BLOCK_OFFSET_VALID && local_file);\n> ret = bdrv_co_block_status(local_file, mapping,\n> - ret & BDRV_BLOCK_OFFSET_MASK,\n> + (ret & BDRV_BLOCK_OFFSET_MASK) |\n> + (offset & ~BDRV_BLOCK_OFFSET_MASK),\n> *pnum, pnum, &local_file);\n> - assert(QEMU_IS_ALIGNED(*pnum, BDRV_SECTOR_SIZE));\n> goto out;\n> }\n> \n> @@ -1860,7 +1878,8 @@ static int64_t coroutine_fn bdrv_co_block_status(BlockDriverState *bs,\n> int64_t file_pnum;\n> \n> ret2 = bdrv_co_block_status(local_file, mapping,\n> - ret & BDRV_BLOCK_OFFSET_MASK,\n> + (ret & BDRV_BLOCK_OFFSET_MASK) |\n> + (offset & ~BDRV_BLOCK_OFFSET_MASK),\n> *pnum, &file_pnum, NULL);\n> if (ret2 >= 0) {\n> /* Ignore errors. This is just providing extra information, it\n> diff --git a/block/blkdebug.c b/block/blkdebug.c\n> index 46e53f2f09..f54fe33cae 100644\n> --- a/block/blkdebug.c\n> +++ b/block/blkdebug.c\n> @@ -628,6 +628,17 @@ static int coroutine_fn blkdebug_co_pdiscard(BlockDriverState *bs,\n> return bdrv_co_pdiscard(bs->file->bs, offset, bytes);\n> }\n> \n> +static int64_t coroutine_fn blkdebug_co_get_block_status(\n> + BlockDriverState *bs, int64_t sector_num, int nb_sectors, int *pnum,\n> + BlockDriverState **file)\n> +{\n> + assert(QEMU_IS_ALIGNED(sector_num | nb_sectors,\n> + DIV_ROUND_UP(bs->bl.request_alignment,\n> + BDRV_SECTOR_SIZE)));\n> + return bdrv_co_get_block_status_from_file(bs, sector_num, nb_sectors,\n> + pnum, file);\n> +}\n> +\n> static void blkdebug_close(BlockDriverState *bs)\n> {\n> BDRVBlkdebugState *s = bs->opaque;\n> @@ -897,7 +908,7 @@ static BlockDriver bdrv_blkdebug = {\n> .bdrv_co_flush_to_disk = blkdebug_co_flush,\n> .bdrv_co_pwrite_zeroes = blkdebug_co_pwrite_zeroes,\n> .bdrv_co_pdiscard = blkdebug_co_pdiscard,\n> - .bdrv_co_get_block_status = bdrv_co_get_block_status_from_file,\n> + .bdrv_co_get_block_status = blkdebug_co_get_block_status,\n> \n> .bdrv_debug_event = blkdebug_debug_event,\n> .bdrv_debug_breakpoint = blkdebug_debug_breakpoint,\n> \n\nLooks good overall but I have some comprehension issues in my own head\nabout the adjustment math and why the various alignments are safe.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@gnu.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=jsnow@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 3y5YZQ5h8Qz9sP1\n\tfor ;\n\tTue, 3 Oct 2017 07:25:34 +1100 (AEDT)","from localhost ([::1]:54678 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dz7HP-0003Cj-Nj\n\tfor incoming@patchwork.ozlabs.org; Mon, 02 Oct 2017 16:25:31 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:52001)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dz7H2-00037K-JE\n\tfor qemu-devel@nongnu.org; Mon, 02 Oct 2017 16:25:10 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dz7H1-00013K-3p\n\tfor qemu-devel@nongnu.org; Mon, 02 Oct 2017 16:25:08 -0400","from mx1.redhat.com ([209.132.183.28]:44896)\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 1dz7Gu-0000t4-Ga; Mon, 02 Oct 2017 16:25:00 -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 820727E43D;\n\tMon, 2 Oct 2017 20:24:59 +0000 (UTC)","from [10.10.125.14] (ovpn-125-14.rdu2.redhat.com [10.10.125.14])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 9405560178;\n\tMon, 2 Oct 2017 20:24:51 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 820727E43D","To":"Eric Blake , qemu-devel@nongnu.org","References":"<20170913160333.23622-1-eblake@redhat.com>\n\t<20170913160333.23622-22-eblake@redhat.com>","From":"John Snow ","Message-ID":"<2d443ce7-b533-cd70-0e60-1bba52ac6d69@redhat.com>","Date":"Mon, 2 Oct 2017 16:24:51 -0400","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":"<20170913160333.23622-22-eblake@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","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\tMon, 02 Oct 2017 20:24:59 +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 v4 21/23] block: Align block status requests","X-BeenThere":"qemu-devel@gnu.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":"kwolf@redhat.com, famz@redhat.com, Stefan Hajnoczi ,\n\tqemu-block@nongnu.org, Max Reitz ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@gnu.org","Sender":"\"Qemu-devel\"\n\t"}}]