From patchwork Mon Feb 4 10:40:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Tokarev X-Patchwork-Id: 217922 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 0F23E2C02AB for ; Tue, 5 Feb 2013 00:33:05 +1100 (EST) Received: from localhost ([::1]:41559 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Jab-00025F-F1 for incoming@patchwork.ozlabs.org; Mon, 04 Feb 2013 05:47:53 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2JaA-0001tt-5U for qemu-devel@nongnu.org; Mon, 04 Feb 2013 05:47:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2Ja8-0002TZ-MC for qemu-devel@nongnu.org; Mon, 04 Feb 2013 05:47:26 -0500 Received: from isrv.corpit.ru ([86.62.121.231]:52332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Ja8-0002TI-FB; Mon, 04 Feb 2013 05:47:24 -0500 Received: from gandalf.tls.msk.ru (mjt.vpn.tls.msk.ru [192.168.177.99]) by isrv.corpit.ru (Postfix) with ESMTP id 89A3DA03E6; Mon, 4 Feb 2013 14:47:23 +0400 (MSK) Received: by gandalf.tls.msk.ru (Postfix, from userid 1000) id 3BA29534; Mon, 4 Feb 2013 14:41:28 +0400 (MSK) From: Michael Tokarev To: qemu-devel@nongnu.org Date: Mon, 4 Feb 2013 14:40:42 +0400 Message-Id: <1359974470-17044-33-git-send-email-mjt@msgid.tls.msk.ru> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1359974470-17044-1-git-send-email-mjt@msgid.tls.msk.ru> References: <1359974470-17044-1-git-send-email-mjt@msgid.tls.msk.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 86.62.121.231 Cc: Kevin Wolf , Michael Tokarev , qemu-stable@nongnu.org, Stefan Hajnoczi Subject: [Qemu-devel] [PATCH 32/60] qed: refuse unaligned zero writes with a backing file X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org From: Stefan Hajnoczi Zero writes have cluster granularity in QED. Therefore they can only be used to zero entire clusters. If the zero write request leaves sectors untouched, zeroing the entire cluster would obscure the backing file. Instead return -ENOTSUP, which is handled by block.c:bdrv_co_do_write_zeroes() and falls back to a regular write. The qemu-iotests 034 test cases covers this scenario. Signed-off-by: Stefan Hajnoczi Reviewed-by: Paolo Bonzini Signed-off-by: Kevin Wolf (cherry picked from commit ef72f76e58107bd4096018c3db2912d28249308e) Signed-off-by: Michael Tokarev --- block/qed.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/block/qed.c b/block/qed.c index 30a31f9..49ac93e 100644 --- a/block/qed.c +++ b/block/qed.c @@ -1370,10 +1370,21 @@ static int coroutine_fn bdrv_qed_co_write_zeroes(BlockDriverState *bs, int nb_sectors) { BlockDriverAIOCB *blockacb; + BDRVQEDState *s = bs->opaque; QEDWriteZeroesCB cb = { .done = false }; QEMUIOVector qiov; struct iovec iov; + /* Refuse if there are untouched backing file sectors */ + if (bs->backing_hd) { + if (qed_offset_into_cluster(s, sector_num * BDRV_SECTOR_SIZE) != 0) { + return -ENOTSUP; + } + if (qed_offset_into_cluster(s, nb_sectors * BDRV_SECTOR_SIZE) != 0) { + return -ENOTSUP; + } + } + /* Zero writes start without an I/O buffer. If a buffer becomes necessary * then it will be allocated during request processing. */