From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538759; cv=none; d=zohomail.com; s=zohoarc; b=FAhL/DwRFv0mDWzZVvW+K989/AdzXfjZLwz5uChfSObXVc+P9UN5OYY+LVJShikIefocENGx0a2WZ3aQjHZw5mheRLaMo4Gv3KwtIMwYR4eC0oUp6tqKSBip2iZtRZays3QFn9KsdSLsNEQd/rW5nD+7iph4NFYjCe+h/z66D80= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538759; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=TO+F2pc2vn4cH6gj+eUGA+TbOU46rfxX7z+qzRTHsOk=; b=FylD8R5AH8KrW+/Y/yr9XpJbL1vLyqnYkcf9kAsCn3xxy6xVU7O9h3EQJNNVpSZ86wGCsnGClOraLukqMrUH+/fklK7Ik2GGuCFTy1rmAORZ/vf6RQ9qQG1oCNHk0tNC8vvvkjB4mYt/WUc6cXs9NqCoOO4dIJyFKzFQ8BikQ38= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538759512369.4812552082428; Fri, 4 Sep 2026 09:19:19 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2WcJ-0000Tt-VG; Fri, 04 Sep 2026 12:18:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcI-0000Sz-M8; Fri, 04 Sep 2026 12:18:14 -0400 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcH-0001Hn-67; Fri, 04 Sep 2026 12:18:14 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 9030460211; Fri, 4 Sep 2026 16:18:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6CADE1F00A3D; Fri, 4 Sep 2026 16:18:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538691; bh=TO+F2pc2vn4cH6gj+eUGA+TbOU46rfxX7z+qzRTHsOk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hbJUEgiojT1Qbh29+oBjqKlgngjidjQEFQhHErr7Uke3c7uWrms/4aQ+KbYFdygE1 bYuMDav+uE5c/K6W1gPLvoABvg1Dq8ZJeOptpydqpbpEfhcAJ+9748LByQ8vj2gLsV WjGMdPLtM+uWV+6bXfef3wqQHxmyVyd6OyHh5vYnejupzioZiVxHbbX+nL1oCpnY8L 3CiN3PW+/Pw0BcVTrAahEOZXbf5Eq7cxF7/G3NdZOsgFAOCZhryfeqvBbf3u4OR8Hz 0f5I7HFsK9MSeiz5a1H0fdG4cIXPvTJRfBGfL/XcjOGx97egA30lbkN+T9TqBR6p7s RN1Gobfn9Unbg== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 01/12] block: widen BlockLimits.zone_size to uint64_t Date: Fri, 4 Sep 2026 18:17:49 +0200 Message-ID: <20260904161801.1568841-2-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c04:e001:324:0:1991:8:25; envelope-from=cassel@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538763672158500 Content-Type: text/plain; charset="utf-8" From: Sam Li The zone-size field in BlockLimits is currently uint32_t, capping expressible zone sizes at 4 GiB. Real zoned-device protocols like NVMe ZNS allow larger zones. Widen BlockLimits.zone_size to uint64_t to match. Signed-off-by: Sam Li Reviewed-by: Niklas Cassel Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/file-posix.c | 2 +- include/block/block_int-common.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index 9aad156aad..c0d6ee30e4 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -3598,7 +3598,7 @@ raw_co_zone_append(BlockDriverState *bs, =20 if (*offset & zone_size_mask) { error_report("sector offset %" PRId64 " is not aligned to zone siz= e " - "%" PRId32 "", *offset / 512, bs->bl.zone_size / 512); + "%" PRId64 "", *offset / 512, bs->bl.zone_size / 512); return -EINVAL; } =20 diff --git a/include/block/block_int-common.h b/include/block/block_int-com= mon.h index 147c08155f..7571ed9968 100644 --- a/include/block/block_int-common.h +++ b/include/block/block_int-common.h @@ -901,7 +901,7 @@ typedef struct BlockLimits { BlockZoneModel zoned; =20 /* zone size expressed in bytes */ - uint32_t zone_size; + uint64_t zone_size; =20 /* total number of zones */ uint32_t nr_zones; --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538864; cv=none; d=zohomail.com; s=zohoarc; b=ln8hJm88BYaqizGvadNpQBmrPzNyA8q2ptDa2d1mR3D4cyB+cvFvE+PSQUs4dNAe285E1vOybo+cbiXqhNgAx28FH2UJZqhtBpFUgrFGKua2jANu+ZbnX+tTA26n8AD/g1q1VvZWuL3z9pVRHwUCRJjYzSWSjVCPsKONTvieXnk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538864; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=TFg7avD/j58roO41WzcRhKlbi6ueX70eH3NQ2e75uBA=; b=GufEbk8ANnMdNWvtbwj+yvMvMRRSRpA4V1CSwO5BV+rvcYVgKrZvZBY3eXu8BtNhDAZndBmsiXKkIok+MaagkP+fHydgjPVxYXDarnlZ9E+9Z1zgXdnAkXDid43gryht5z8BzmBk0dEas0IXDLdQx8rL6lNPZSufhWKud2HBgA8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538864862925.2119472562612; Fri, 4 Sep 2026 09:21:04 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2WcN-0000VH-HT; Fri, 04 Sep 2026 12:18:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcL-0000US-Cx; Fri, 04 Sep 2026 12:18:17 -0400 Received: from sea.source.kernel.org ([172.234.252.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcJ-0001Ij-Df; Fri, 04 Sep 2026 12:18:17 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 06C6A43E45; Fri, 4 Sep 2026 16:18:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D51601F00A3D; Fri, 4 Sep 2026 16:18:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538693; bh=TFg7avD/j58roO41WzcRhKlbi6ueX70eH3NQ2e75uBA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=gOKvuquuEvGXUtOQuOdocnNaiEdCGV4iWTbJJp0JmtCFw+SRD4ZgKF/FtbMWvzT2A HQyBg0c8iaPMAQUind2/etPOFVfN8c4j96JKpiNl2oMSruhP6c/UyBQrrQNs6HCloD JhVxurCRQrUcnwrvmTqqaxbL64lPLZXdXyEqSx81kHYuW3bO/9Vl2txGdLpxZraEHh dbh34j+R/TLKBiWjybhGwrfqxyCiRA3dEXgh2uYCTonSpJ9dnSFS4yS3qtCmVgbSZx C9TJqxNU5Td5zFxkWqMKL4tEb8/heep88Bh0kiXGz7wGBjKuljOpOqJR1r+Tt3qqFt CxMKlGq9kj6LA== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz , "Michael S. Tsirkin" Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 02/12] virtio-blk: do not merge requests across a zone boundary Date: Fri, 4 Sep 2026 18:17:50 +0200 Message-ID: <20260904161801.1568841-3-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=172.234.252.31; envelope-from=cassel@kernel.org; helo=sea.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538866575154100 Content-Type: text/plain; charset="utf-8" From: Sam Li virtio_blk_submit_multireq() fuses adjacent in-zone requests into a single request. On a zoned backend, a merged zone append request that straddles a zone boundary is rejected by the device because each write/read must stay within a single zone (virtio 1.4, 5.2.6.1). Add a bail condition to the merge coalescer: if combining the candidate request into the current batch would cross a zone boundary, flush the current batch and start a new one. Signed-off-by: Sam Li Reviewed-by: Damien Le Moal Reviewed-by: Stefan Hajnoczi Reviewed-by: Niklas Cassel Signed-off-by: Niklas Cassel --- block/block-backend.c | 11 +++++++++++ hw/block/virtio-blk.c | 22 +++++++++++++++++++++- include/system/block-backend-io.h | 1 + 3 files changed, 33 insertions(+), 1 deletion(-) diff --git a/block/block-backend.c b/block/block-backend.c index 37ba7e9fc4..049e70ddcb 100644 --- a/block/block-backend.c +++ b/block/block-backend.c @@ -2326,6 +2326,17 @@ uint32_t blk_get_request_alignment(BlockBackend *blk) return bs ? bs->bl.request_alignment : BDRV_SECTOR_SIZE; } =20 +/* + * Returns the zone size in bytes for a zoned backend, or 0 if @blk does + * not present zoned geometry. + */ +uint64_t blk_get_zone_size(BlockBackend *blk) +{ + BlockDriverState *bs =3D blk_bs(blk); + IO_CODE(); + return bs ? bs->bl.zone_size : 0; +} + /* Returns the optimal write zeroes alignment, in bytes; guaranteed nonzer= o */ uint32_t blk_get_pwrite_zeroes_alignment(BlockBackend *blk) { diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 6b92066aff..ffcd327803 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -294,6 +294,9 @@ static void virtio_blk_submit_multireq(VirtIOBlock *s, = MultiReqBuffer *mrb) int i =3D 0, start =3D 0, num_reqs =3D 0, niov =3D 0, nb_sectors =3D 0; uint32_t max_transfer; int64_t sector_num =3D 0; + uint64_t zone_size =3D blk_get_zone_size(s->blk); + bool zone_cross; + int64_t zone_nr_sectors, end_sector; =20 if (mrb->num_reqs =3D=3D 1) { submit_requests(s, mrb, 0, 1, -1); @@ -309,17 +312,34 @@ static void virtio_blk_submit_multireq(VirtIOBlock *s= , MultiReqBuffer *mrb) for (i =3D 0; i < mrb->num_reqs; i++) { VirtIOBlockReq *req =3D mrb->reqs[i]; if (num_reqs > 0) { + /* + * On zoned backends, a single backend write/read must not span + * a zone boundary. Bail out of merging if combining req into + * the current batch would straddle a zone. + */ + if (zone_size > 0) { + zone_nr_sectors =3D zone_size / BDRV_SECTOR_SIZE; + end_sector =3D req->sector_num + + req->qiov.size / BDRV_SECTOR_SIZE - 1; + zone_cross =3D (sector_num / zone_nr_sectors) !=3D + (end_sector / zone_nr_sectors); + } else { + zone_cross =3D false; + } + /* * NOTE: We cannot merge the requests in below situations: * 1. requests are not sequential * 2. merge would exceed maximum number of IOVs * 3. merge would exceed maximum transfer length of backend de= vice + * 4. merge would cross a zone boundary on a zoned backend */ if (sector_num + nb_sectors !=3D req->sector_num || niov > blk_get_max_iov(s->blk) - req->qiov.niov || req->qiov.size > max_transfer || nb_sectors > (max_transfer - - req->qiov.size) / BDRV_SECTOR_SIZE) { + req->qiov.size) / BDRV_SECTOR_SIZE || + zone_cross) { submit_requests(s, mrb, start, num_reqs, niov); num_reqs =3D 0; } diff --git a/include/system/block-backend-io.h b/include/system/block-backe= nd-io.h index fd84723d9d..78d410b8df 100644 --- a/include/system/block-backend-io.h +++ b/include/system/block-backend-io.h @@ -121,6 +121,7 @@ uint32_t blk_get_request_alignment(BlockBackend *blk); uint32_t blk_get_pwrite_zeroes_alignment(BlockBackend *blk); uint32_t blk_get_max_transfer(BlockBackend *blk); uint64_t blk_get_max_hw_transfer(BlockBackend *blk); +uint64_t blk_get_zone_size(BlockBackend *blk); =20 int coroutine_fn blk_co_copy_range(BlockBackend *blk_in, int64_t off_in, BlockBackend *blk_out, int64_t off_out, --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538727; cv=none; d=zohomail.com; s=zohoarc; b=PCL7f+3MWt37i+Z2BkFYHHHqJa1WhhiCwDsYel4DoahLbGLUfRMxqvy1gse3DbPeMNKcpbzXiLt3Nf/2JsH9abcRh8CA5ktkXTqaZamiOKDdnpXYxqMv2b7w/fN93iQEJlCPWmio9ZvpFz2o9I7LjOlnoWWK6Azb9PXWgH2/2rY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538727; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=Vl9F/hDoAxFJfb47pT+Ws99N4unPk5C+HlgiMxsOiQY=; b=JwZfhKK/Nmo89pqvdnuu+dyT/rFakoJjsTzePkH6PrEl1daAHtFGWe2AQJ8JC6bYhG2SigEqRi4UWpf3y0/dzIJMlxXdZ2RPg+R9LupKGrZQiyC8SvjWcJt9HOY0C8blzqbMD7ZQwKgzHFs53epvt42ntfAQ1udTgmRIr0TdDfM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538727120352.40939226599266; Fri, 4 Sep 2026 09:18:47 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2WcO-0000Vg-Vq; Fri, 04 Sep 2026 12:18:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcN-0000VQ-KI; Fri, 04 Sep 2026 12:18:19 -0400 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcL-0001KG-W6; Fri, 04 Sep 2026 12:18:19 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 03B476020A; Fri, 4 Sep 2026 16:18:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78E561F00A3D; Fri, 4 Sep 2026 16:18:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538696; bh=Vl9F/hDoAxFJfb47pT+Ws99N4unPk5C+HlgiMxsOiQY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=X3W/Er0HCxeS+l7eI9EuefqoKKov/Vmd+bU6LioTdFydqWbcQN7qf7EGgLGoLhbJ/ xijl0pWl98NROaM51FIhGnJF34AdbPVCdABGfBY7P+atzpKdr2pEwQUd5zItiy/FRa oGaPWytSr9ntTpAaSTuvGcZ2FVaPSedyPf/+QmZZa0hxXKBpFAOk9IVled+6cwwTtn ZhSzzgkFZaY1s+piiVQDZReUm8bWDoz12p93cCZkVWk14SK+9Cg+Uhibi002QQ/SQq Fcnrn4uDjnaGaquaKgESBnaB1TCDsPvxFRMClXKG/u5axJyYrOjymGTaWEBt59sMKg lHhN/k6v8A4FA== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz , Fam Zheng , "Michael S. Tsirkin" Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 03/12] block: add a helper for the index of the zone an offset falls in Date: Fri, 4 Sep 2026 18:17:51 +0200 Message-ID: <20260904161801.1568841-4-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c04:e001:324:0:1991:8:25; envelope-from=cassel@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538728574154100 Content-Type: text/plain; charset="utf-8" Deriving the zone that an offset belongs to is open coded in five places, in two files, as a division of the offset by BlockLimits.zone_size. The zone size of a zoned device is always a power of two, which Linux requires of every device it accepts, so the division is a shift. Add bdrv_zone_index() and use it. No functional change; the count of zones that a management operation spans stays a division, since it is a length rather than an offset. Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal --- block/file-posix.c | 8 ++++---- block/io.c | 7 +++++++ hw/block/virtio-blk.c | 2 +- include/block/block-io.h | 5 +++++ 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index c0d6ee30e4..00323f7a9f 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -1359,7 +1359,7 @@ static int get_zones_wp(BlockDriverState *bs, int fd,= int64_t offset, size_t rep_size; uint64_t sector =3D offset >> BDRV_SECTOR_BITS; BlockZoneWps *wps =3D bs->wps; - unsigned int j =3D offset / bs->bl.zone_size; + unsigned int j =3D bdrv_zone_index(bs, offset); unsigned int n =3D 0, i =3D 0; int ret; rep_size =3D sizeof(struct blk_zone_report) + nrz * sizeof(struct blk_= zone); @@ -2560,7 +2560,7 @@ raw_co_prw(BlockDriverState *bs, int64_t *offset_ptr,= uint64_t bytes, bs->bl.zoned !=3D BLK_Z_NONE) { qemu_co_mutex_lock(&bs->wps->colock); if (type & QEMU_AIO_ZONE_APPEND) { - int index =3D offset / bs->bl.zone_size; + int index =3D bdrv_zone_index(bs, offset); offset =3D bs->wps->wp[index]; } } @@ -2615,7 +2615,7 @@ out: bs->bl.zoned !=3D BLK_Z_NONE) { BlockZoneWps *wps =3D bs->wps; if (ret =3D=3D 0) { - uint64_t *wp =3D &wps->wp[offset / bs->bl.zone_size]; + uint64_t *wp =3D &wps->wp[bdrv_zone_index(bs, offset)]; if (!BDRV_ZT_IS_CONV(*wp)) { if (type & QEMU_AIO_ZONE_APPEND) { *offset_ptr =3D *wp; @@ -3513,7 +3513,7 @@ static int coroutine_fn raw_co_zone_mgmt(BlockDriverS= tate *bs, BlockZoneOp op, return -EINVAL; } =20 - uint32_t i =3D offset / bs->bl.zone_size; + uint32_t i =3D bdrv_zone_index(bs, offset); uint32_t nrz =3D len / bs->bl.zone_size; uint64_t *wp =3D &wps->wp[i]; if (BDRV_ZT_IS_CONV(*wp) && len !=3D capacity) { diff --git a/block/io.c b/block/io.c index a916b236c3..497247b684 100644 --- a/block/io.c +++ b/block/io.c @@ -3361,6 +3361,13 @@ out: return co.ret; } =20 +uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_t offset) +{ + IO_CODE(); + + return offset >> ctz64(bs->bl.zone_size); +} + void *qemu_blockalign(BlockDriverState *bs, size_t size) { IO_CODE(); diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index ffcd327803..8c5b87793e 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -527,7 +527,7 @@ static bool check_zoned_request(VirtIOBlock *s, int64_t= offset, int64_t len, } } =20 - index =3D offset / bs->bl.zone_size; + index =3D bdrv_zone_index(bs, offset); if (BDRV_ZT_IS_CONV(bs->wps->wp[index])) { *status =3D VIRTIO_BLK_S_ZONE_INVALID_CMD; return false; diff --git a/include/block/block-io.h b/include/block/block-io.h index d34d846bb2..71c8cdf2e1 100644 --- a/include/block/block-io.h +++ b/include/block/block-io.h @@ -126,6 +126,11 @@ int coroutine_fn GRAPH_RDLOCK bdrv_co_zone_append(Bloc= kDriverState *bs, int64_t *offset, QEMUIOVector *qiov, BdrvRequestFlags flags); +/* + * The index of the zone that @offset falls in. A zoned device always has a + * zone size that is a power of two, so the division is a shift. + */ +uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_t offset); =20 bool bdrv_can_write_zeroes_with_unmap(BlockDriverState *bs); =20 --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538759; cv=none; d=zohomail.com; s=zohoarc; b=KGXxIB3PhZh33jtxk/IfANh2ZYkspzksdrDYwJshXVgnys1nDqILREQB/EqHzlRQ/vbrENlNDPvq8zmk1tchaRHsE5I6cDMCfhQdjsByh6f9vKVyFf+4oThOHmq5PXeFdhEL82FDOaqkwWfgKfyEybnKD46m83M+mFtMINr+NzU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538759; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=6In/0Mws2BMD9gkRJbFioNelwcbx/otmGgYGfdAxe4M=; b=H1lfINDif1TJmzZiXUIAzhLVR+/Gm4y37DK7fzMuCoPEaAphtL7A+ovjLlKc7ZYqxjqMQhojcJgRDc+wL9PSEMGMBwve2Ebe0OAs56gvoulzVW4vw8anuTCs/wD1QIyqzYs2By1D3AUe15Li27TPBLf7JV5qrtDABh6bUS0DZBA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538759444930.2963989520125; Fri, 4 Sep 2026 09:19:19 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2WcS-0000Wg-1z; Fri, 04 Sep 2026 12:18:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcQ-0000WJ-Nc; Fri, 04 Sep 2026 12:18:22 -0400 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcP-0001Lg-0H; Fri, 04 Sep 2026 12:18:22 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 0084360211; Fri, 4 Sep 2026 16:18:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 480EE1F00A3D; Fri, 4 Sep 2026 16:18:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538699; bh=6In/0Mws2BMD9gkRJbFioNelwcbx/otmGgYGfdAxe4M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=n+yLv51vUlYkUHt1p04HunZa7uweIQ5pJtqDVei/IZK9wv+1tWkq4vZZfpCQBAJ7o Q73sY6/20JUAWeT659XKOWKl287XQtfz3Ttb8sIV+2f84MNIvjHsMuI81bwnGA4V2F YbkIPDdunYiyUzDHReoThvKTghfJgYU22EeeDzKHD7629hSFoKv6Nx0YPSeG0GypkD nSGN/EXTU/zSrDAFIJPF/YqLRRtruN9FJsooxzcovCsuBeX6VEpwtNkaM/MVrYw0Zu BUKszN4bUbL6NUXhlGzzbs97E7SXhO7yhaK8KRV/m5i/T0NTNLpOd66TWOg6R6xIK1 majIPgdCsFEOA== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , John Snow , "Denis V. Lunev" , Hanna Reitz , "Michael S. Tsirkin" Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 04/12] virtio-blk: report the effective zone write granularity Date: Fri, 4 Sep 2026 18:17:52 +0200 Message-ID: <20260904161801.1568841-5-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c04:e001:324:0:1991:8:25; envelope-from=cassel@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538761743158500 Content-Type: text/plain; charset="utf-8" For ZBC/ZAC devices the write granularity is the physical block size, so a 512e SMR disk exposed through a host_device backend has a logical block size of 512 and a zone write granularity of 4096. We told the guest driver = 512 while raw_co_zone_append() rejects anything that is not 4096 byte aligned, so the driver saw a plain I/O error for a request it had been told was valid. Report the larger of the backend granularity and the logical block size instead. The guest driver cannot issue writes finer than the logical size, so the larger of the two is the constraint that applies. This matches what a Linux guest derives for itself: blk_validate_zoned_limits() raises zone_write_granularity to the logical block size, and blk_stack_limits() stacks it with max(). Add it as a helper next to blkconf_blocksizes(), since it is derived from a BlockConf and the limits of the backend below it, and use it for the zone append offset check in check_zoned_request(), which validated against bs->bl.write_granularity. The value reported to the driver and the value that requests are validated against then cannot drift apart. The helper cannot return zero because blkconf_blocksizes() always leaves a logical block size behind, so the check no longer needs to guard against an unset granularity. Fixes: 4f7366506a96 ("virtio-blk: add zoned storage emulation for zoned dev= ices") Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- hw/block/block.c | 7 +++++++ hw/block/virtio-blk.c | 13 +++++++------ include/hw/block/block.h | 8 ++++++++ 3 files changed, 22 insertions(+), 6 deletions(-) diff --git a/hw/block/block.c b/hw/block/block.c index f187fa025d..1c3135843d 100644 --- a/hw/block/block.c +++ b/hw/block/block.c @@ -201,6 +201,13 @@ bool blkconf_blocksizes(BlockConf *conf, Error **errp) return true; } =20 +uint32_t blkconf_zone_write_granularity(BlockConf *conf) +{ + BlockDriverState *bs =3D blk_bs(conf->blk); + + return MAX(bs->bl.write_granularity, conf->logical_block_size); +} + bool blkconf_apply_backend_options(BlockConf *conf, bool readonly, bool resizable, Error **errp) { diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 8c5b87793e..f6781ff5f6 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -520,11 +520,11 @@ static bool check_zoned_request(VirtIOBlock *s, int64= _t offset, int64_t len, } =20 if (append) { - if (bs->bl.write_granularity) { - if ((offset % bs->bl.write_granularity) !=3D 0) { - *status =3D VIRTIO_BLK_S_ZONE_UNALIGNED_WP; - return false; - } + uint32_t wg_mask =3D blkconf_zone_write_granularity(&s->conf.conf)= - 1; + + if (offset & wg_mask) { + *status =3D VIRTIO_BLK_S_ZONE_UNALIGNED_WP; + return false; } =20 index =3D bdrv_zone_index(bs, offset); @@ -1274,7 +1274,8 @@ static void virtio_blk_update_config(VirtIODevice *vd= ev, uint8_t *config) bs->bl.max_active_zones); virtio_stl_p(vdev, &blkcfg.zoned.max_open_zones, bs->bl.max_open_zones); - virtio_stl_p(vdev, &blkcfg.zoned.write_granularity, blk_size); + virtio_stl_p(vdev, &blkcfg.zoned.write_granularity, + blkconf_zone_write_granularity(conf)); virtio_stl_p(vdev, &blkcfg.zoned.max_append_sectors, bs->bl.max_append_sectors); } else { diff --git a/include/hw/block/block.h b/include/hw/block/block.h index df941df19f..f98525c01a 100644 --- a/include/hw/block/block.h +++ b/include/hw/block/block.h @@ -114,6 +114,14 @@ bool blkconf_geometry(BlockConf *conf, int *trans, unsigned cyls_max, unsigned heads_max, unsigned secs= _max, Error **errp); bool blkconf_blocksizes(BlockConf *conf, Error **errp); +/* + * The alignment constraint that applies to writes to a sequential zone. T= he + * medium may require a coarser granularity than the logical block size, w= hile + * a guest cannot issue writes finer than the logical block size, so the + * constraint that applies is the larger of the two. A frontend must repor= t this + * value to its guest and validate requests against it. + */ +uint32_t blkconf_zone_write_granularity(BlockConf *conf); bool blkconf_apply_backend_options(BlockConf *conf, bool readonly, bool resizable, Error **errp); =20 --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538803; cv=none; d=zohomail.com; s=zohoarc; b=NqKeRHTD7AtXaBIgbmZmc5IGUYmqx4zRUNrkS0AHz+tHwQxQqiE02sMN5aYJM9Xu8PnJrG9fyex9Ew3uJ9RONwapk/jcvI41QSpgyd7ISFwCYFqs1cNEBhYFaKtGtC4/J0JZEEFd9jxb0DWXGHPhiqiljFWoZ/33kAba9n8c+cw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538803; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=n+jP/Vgtq0cso0u8LM7AN9MQnrd9u1JYkEnESAAfIfQ=; b=OYNzJnSo77kV0tCMkI1kGoslF/y1dVXt3bSU02Wi3Z3+5FXMqojsemFwFPhaMWqIo+JUGHXDXAoV4Hds8MvVnnPpTwwFAjfqW8JoDO+MMWpZJyUzphBo9afMureIDwO1N4AUrUxmvcRny6B8Y5ZdrYyDjcn8VTB78gK7Nu2iMPI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538803477311.2836391033279; Fri, 4 Sep 2026 09:20:03 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2WcW-0000ZV-5B; Fri, 04 Sep 2026 12:18:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcT-0000YF-EK; Fri, 04 Sep 2026 12:18:25 -0400 Received: from sea.source.kernel.org ([172.234.252.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcR-0001MU-JU; Fri, 04 Sep 2026 12:18:25 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 6220443EDA; Fri, 4 Sep 2026 16:18:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CAD81F00A3D; Fri, 4 Sep 2026 16:18:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538702; bh=n+jP/Vgtq0cso0u8LM7AN9MQnrd9u1JYkEnESAAfIfQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hN7j8YGn/wZ1iuCTa0kzuDflA1WZ97qkPolfdtK2HRGbCuBavgxwK/e1yS8VGOd/h RSYW0eXPxlFBV3mP1KDJIUbKUOUqhFDW3yh8pMJuxwsfP5RmOqRH1nVzJ7P5Q70RSK t3OCx+XcNRtos/ox+KF9MTlB22l3iuIMd5yGsDNh/XB2LrfJUtYf4A19iT9WJijzI5 I8USlSBB9GLVE8U5EPlVBo7JWI1WrfyBETb2xTWR9MVQqQDXq/RYR8K9RWApAa0MiU z76aISBJpu5TFO1u1O/8Ep0syJNEawZkl7TcVGs6Geeu4/l2A0BthYNOCjkJKpgNHt HqJQqsaoQTcFw== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , "Michael S. Tsirkin" , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 05/12] virtio-blk: check the write granularity of writes to sequential zones Date: Fri, 4 Sep 2026 18:17:53 +0200 Message-ID: <20260904161801.1568841-6-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=172.234.252.31; envelope-from=cassel@kernel.org; helo=sea.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538805778154100 Content-Type: text/plain; charset="utf-8" All VIRTIO_BLK_T_OUT requests issued to sequential zones and all VIRTIO_BLK_T_ZONE_APPEND requests must have an offset and a data size that are multiples of the write granularity reported by the device (virtio 1.4, 5.2.6.1), and a violation is reported as VIRTIO_BLK_S_ZONE_UNALIGNED_WP (virtio 1.4, 5.2.6). Neither request type was fully checked. Zone appends validated only the offset, while writes were not checked at all. Check the size of the appended data, and both the offset and the size of a write, against blkconf_zone_write_granularity(), so that every request the device accepts is one that the guest driver was told is valid. Writes to conventional zones keep no alignment constraint beyond the logical block size. The write path performs the check after virtio_blk_sect_range_ok() so that the zone index derived from the guest supplied sector is known to be in range. Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal --- hw/block/virtio-blk.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index f6781ff5f6..7d5a02a42c 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -398,6 +398,33 @@ static bool virtio_blk_sect_range_ok(VirtIOBlock *dev, return true; } =20 +/* + * Both the offset and the size of a write to a sequential zone must be a + * multiple of the write granularity that the device reports. Conventional + * zones are not constrained. The zone index is derived from a guest suppl= ied + * sector, so this must only be called once virtio_blk_sect_range_ok() has + * bounded it. + */ +static bool virtio_blk_zone_write_granularity_ok(VirtIOBlock *dev, + uint64_t sector, size_t s= ize) +{ + BlockDriverState *bs =3D blk_bs(dev->blk); + uint64_t offset =3D sector << BDRV_SECTOR_BITS; + uint32_t wg_mask; + + if (bs->bl.zoned =3D=3D BLK_Z_NONE) { + return true; + } + + if (BDRV_ZT_IS_CONV(bs->wps->wp[bdrv_zone_index(bs, offset)])) { + return true; + } + + wg_mask =3D blkconf_zone_write_granularity(&dev->conf.conf) - 1; + + return !(offset & wg_mask) && !(size & wg_mask); +} + static uint8_t virtio_blk_handle_discard_write_zeroes(VirtIOBlockReq *req, struct virtio_blk_discard_write_zeroes *dwz_hdr, bool is_write_zeroes) { @@ -522,7 +549,7 @@ static bool check_zoned_request(VirtIOBlock *s, int64_t= offset, int64_t len, if (append) { uint32_t wg_mask =3D blkconf_zone_write_granularity(&s->conf.conf)= - 1; =20 - if (offset & wg_mask) { + if (offset & wg_mask || len & wg_mask) { *status =3D VIRTIO_BLK_S_ZONE_UNALIGNED_WP; return false; } @@ -911,6 +938,15 @@ static int virtio_blk_handle_request(VirtIOBlockReq *r= eq, MultiReqBuffer *mrb) return 0; } =20 + if (is_write && + !virtio_blk_zone_write_granularity_ok(s, req->sector_num, + req->qiov.size)) { + virtio_blk_req_complete(req, VIRTIO_BLK_S_ZONE_UNALIGNED_WP); + block_acct_invalid(blk_get_stats(s->blk), BLOCK_ACCT_WRITE); + g_free(req); + return 0; + } + block_acct_start(blk_get_stats(s->blk), &req->acct, req->qiov.size, is_write ? BLOCK_ACCT_WRITE : BLOCK_ACCT_READ); =20 --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538801; cv=none; d=zohomail.com; s=zohoarc; b=dC+Fn1yfbiMEWrLRVMABnLsNQH4ZEsl2ZE5coN4cCh9kf0qTnBBCcdbxTSmyX5xiDH2FScUf0NP1HIZ209h4T2wVgbAzXbpQNIx7UxJKL7zblqqAj2dy60QheIb7M+pyHi2Azp8sfmlh/7Zdk90+ku0T7k5Tr8O2tV1ZaVnO/UA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538801; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=SK2JBBjz+EZLOO1NbZL6Re9r4Fej7YKDQm5dLk+zWso=; b=mQzieuSgSCRA9jal2Ng1FH1+ikdn6hVmcJaXR9sFCyO8w4g6kYEY8Q22g6CmbZ14BMISaIvxfSvoV+T39mOKeXkhdECujPUjgEv4o47JQtA2jY9fycdnkfk2rCHyLw6JWeflj9rTT2p5Vy7qtcCqQaeXMsstCtwyZYc4lGrD6wc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538801495541.1485472482316; Fri, 4 Sep 2026 09:20:01 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2WcZ-0000k1-Gr; Fri, 04 Sep 2026 12:18:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcW-0000ZZ-EF; Fri, 04 Sep 2026 12:18:28 -0400 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcU-0001Ns-GV; Fri, 04 Sep 2026 12:18:28 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 8972960211; Fri, 4 Sep 2026 16:18:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D12A01F00A3D; Fri, 4 Sep 2026 16:18:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538705; bh=SK2JBBjz+EZLOO1NbZL6Re9r4Fej7YKDQm5dLk+zWso=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Xcy8rRU78xTxL43iPwYrlAQR1u5qUVrTjI7d0wZlFq/Eie+eliqLb5y7ti0tm+lKK JnxWIXuUWgLKO8ghpFheaZMHwLivY6lM/wKmthOYznsT64ahXoTFiyeYAT7vOCo+AF P474MsoarlZbMemrudTVXSW+ZBpU4jDTU55bV5lZXVVfkKlAHCyg9uZJ4/0OambvaJ ZT5+TfOPVw9jjhTNAn6V7LT/RoxcYYJ6jQN5VDIhmcbys/xcUeKvAnIy231vaYlEUc pFm+dKe9G+l59LUEdyzCp2eBHJuFXXGULW0/D35IVWL+tle23GqkamNd8W0jxI4qBD 99XfRujX9afaw== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , John Snow , "Denis V. Lunev" , Hanna Reitz , "Michael S. Tsirkin" Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 06/12] hw/block: reject a zoned device whose write pointers are unaddressable Date: Fri, 4 Sep 2026 18:17:54 +0200 Message-ID: <20260904161801.1568841-7-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c04:e001:324:0:1991:8:25; envelope-from=cassel@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538804096154100 Content-Type: text/plain; charset="utf-8" The write pointers of a zoned device outlive any particular use of it, whether the device keeps them itself or a backend records them, while the logical block size is a property of the frontend and is chosen afresh every time the device is attached. Nothing ties the two together. A zone written while the device was configured with logical_block_size=3D512 leaves a write pointer that is a multiple of 512, and attaching the same device with logical_block_size=3D4096 makes that pointer unaddressable. Such a pointer is not merely misaligned. The guest addresses the device in logical blocks, and a zone report expresses the write pointer in 512 byte sectors, so the guest is told about a position that does not fall on a logical block boundary. It can neither read nor write there, and the zone can only be recovered by resetting it. The reverse direction is harmless: a pointer laid down with a larger logical block size is still a multiple of a smaller one. On a zoned null_blk device with a logical block size of 512, a 512 byte append to a sequential zone leaves the write pointer half a logical block into it: $ qemu-io --image-opts -n driver=3Dhost_device,filename=3D/dev/nullb0 \ -c "zap -p 0x20000000 0x200" -c "zrp 0x20000000 1" start: 0x100000, len 0x80000, cap 0x80000, wptr 0x100001, zcond:2 Attaching that disk with logical_block_size=3D4096 handed the guest a zone it could not write to. Check at realize time that the zone size and every write pointer of a sequential zone are multiples of the write granularity that the device is about to report, and refuse to start otherwise. The write pointers are already held in memory by the driver, so this costs no I/O. The check uses blkconf_zone_write_granularity(), the same value that a frontend reports to its guest and validates requests against, so the three cannot disagree. Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal --- hw/block/block.c | 46 ++++++++++++++++++++++++++++++++++++++++ hw/block/virtio-blk.c | 4 ++++ include/hw/block/block.h | 1 + 3 files changed, 51 insertions(+) diff --git a/hw/block/block.c b/hw/block/block.c index 1c3135843d..7663e385ca 100644 --- a/hw/block/block.c +++ b/hw/block/block.c @@ -208,6 +208,52 @@ uint32_t blkconf_zone_write_granularity(BlockConf *con= f) return MAX(bs->bl.write_granularity, conf->logical_block_size); } =20 +bool blkconf_check_zoned_geometry(BlockConf *conf, Error **errp) +{ + BlockDriverState *bs =3D blk_bs(conf->blk); + uint32_t wg; + + if (bs->bl.zoned =3D=3D BLK_Z_NONE) { + return true; + } + + wg =3D blkconf_zone_write_granularity(conf); + + if (!QEMU_IS_ALIGNED(bs->bl.zone_size, wg)) { + error_setg(errp, "zone size %" PRIu64 " is not a multiple of the z= one " + "write granularity %" PRIu32, bs->bl.zone_size, wg); + return false; + } + + /* + * A write pointer that is not a multiple of the write granularity doe= s not + * fall on a logical block boundary, so the guest can neither read nor= write + * at it and the zone can only be recovered by resetting it. A backend= that + * records its write pointers, rather than reading them back from a de= vice, + * can hand us such a pointer when the zones were written while the de= vice + * was configured with a smaller logical block size. + */ + for (uint32_t i =3D 0; i < bs->bl.nr_zones; i++) { + uint64_t wp =3D bs->wps->wp[i]; + + if (BDRV_ZT_IS_CONV(wp)) { + continue; + } + + if (!QEMU_IS_ALIGNED(wp, wg)) { + error_setg(errp, "write pointer 0x%" PRIx64 " of zone %" PRIu32 + " is not a multiple of the zone write granularity %" + PRIu32, wp, i, wg); + error_append_hint(errp, "The zones were written with a smaller= " + "logical_block_size. Reset them, or keep usi= ng " + "the smaller size.\n"); + return false; + } + } + + return true; +} + bool blkconf_apply_backend_options(BlockConf *conf, bool readonly, bool resizable, Error **errp) { diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 7d5a02a42c..c2acf59c6d 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -1834,6 +1834,10 @@ static void virtio_blk_device_realize(DeviceState *d= ev, Error **errp) return; } =20 + if (!blkconf_check_zoned_geometry(&conf->conf, errp)) { + return; + } + bs =3D blk_bs(conf->conf.blk); if (bs->bl.zoned !=3D BLK_Z_NONE) { virtio_add_feature(&s->host_features, VIRTIO_BLK_F_ZONED); diff --git a/include/hw/block/block.h b/include/hw/block/block.h index f98525c01a..69b0a085f0 100644 --- a/include/hw/block/block.h +++ b/include/hw/block/block.h @@ -122,6 +122,7 @@ bool blkconf_blocksizes(BlockConf *conf, Error **errp); * value to its guest and validate requests against it. */ uint32_t blkconf_zone_write_granularity(BlockConf *conf); +bool blkconf_check_zoned_geometry(BlockConf *conf, Error **errp); bool blkconf_apply_backend_options(BlockConf *conf, bool readonly, bool resizable, Error **errp); =20 --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538721; cv=none; d=zohomail.com; s=zohoarc; b=Y7Pzq4oJoJiIc6y127NJl1mrKvKREzCLjXfx+Pg880TLEiONdslU+v0QX5OKofIa30F4fRqwpC2eUK1LdxvRMqz9zAEVZWLep7DLBGqD+Ju5k5wcHHC8moraRPxkFuIBi7SCx1Lj0mj0eYCjUF01EwtvjKo/xgXpssmPgOEBf1g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538721; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=PiicBwAq72HkDdAnMPdGC8GyvXZY0yDIQ/2KjOjW5YA=; b=PoWFRzlDYc836dlXdH/gs/29wzm2lxpvEZRSvTThXgDysYbReaIWMBpGWv7ApZMokqW2HxLY4tjZ5WY0N8sJF2c5TXQTUgTQ4elnMBT5SDLAHy4XOxvu8Z8dabsjsgK9cn4PnJj9xeedJVHSFL5wz8Op/vv1mvV7sEqtYF3SrBI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538720995713.8708760801278; Fri, 4 Sep 2026 09:18:40 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2Wca-0000nZ-OB; Fri, 04 Sep 2026 12:18:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcY-0000hH-Rm; Fri, 04 Sep 2026 12:18:30 -0400 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcX-0001Pu-5M; Fri, 04 Sep 2026 12:18:30 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id ED29F40E17; Fri, 4 Sep 2026 16:18:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5B111F00A3D; Fri, 4 Sep 2026 16:18:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538707; bh=PiicBwAq72HkDdAnMPdGC8GyvXZY0yDIQ/2KjOjW5YA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HLANPp/R/3dv1nI9R3NGaIo9T17dThlUnlwMMURUExc8pk0FNYnx+q52jx2JCqbsI ua7ObrQ9Op9I6Fb82Tjv5qIF2b9frE59nOSSTQICM8ALKjLB1zRM43hPpiocLmAaqE /EfCuaCFpaEBpfzifLNevJ0J3GMaugBwGyuJRI2a7ifczip0p0M3BnIkiBlp9lGESY uNhhshHQlWN+EUI4ONryHh3jB5VExY6ZAChTv7kz+qZy0OyE/yii6gPmr4fuYC/hKn gTEw/5K2n6M8Lcl01IQ93rQVAbqSOsT5ZG8lcicMz+7mHg8rRmrHG53FB2O+iwayjI LyLV1vCBVtswA== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Fam Zheng , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 07/12] block: reject zone appends that are not a multiple of the sector size Date: Fri, 4 Sep 2026 18:17:55 +0200 Message-ID: <20260904161801.1568841-8-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c0a:e001:78e:0:1991:8:25; envelope-from=cassel@kernel.org; helo=sea.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538722808154100 Content-Type: text/plain; charset="utf-8" Zone write pointers are tracked and reported in units of BDRV_SECTOR_SIZE, so an append whose data size is not a multiple of it would leave a write pointer that cannot be represented, neither in a BlockZoneDescriptor nor in the virtio and NVMe zone reports derived from one. Nothing states that invariant. file-posix, the only driver that carries out an append itself, does enforce it, but only as a side effect of checking each iovec against BlockLimits.write_granularity, which is never smaller than the sector size. That conflates two constraints: the sector granularity holds for every driver, whereas write_granularity describes a coarser requirement of the medium below a driver, and only a driver that has such a medium should express it. Check the invariant once in bdrv_co_zone_append(), so that it no longer rests on a driver that happens to have a granularity of its own to report. This is a lower bound, not the alignment that a guest has to observe. The block layer cannot know that one, because it also depends on the logical block size the device is configured with, which is a property of the frontend. The alignment that applies to a guest is the larger of the two, and it is the frontend that reports it, that validates requests against it, and that has to refuse a device whose write pointers do not satisfy it. Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/io.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/block/io.c b/block/io.c index 497247b684..b59c7fdf3e 100644 --- a/block/io.c +++ b/block/io.c @@ -3350,6 +3350,16 @@ int coroutine_fn bdrv_co_zone_append(BlockDriverStat= e *bs, int64_t *offset, return ret; } =20 + /* + * Zone write pointers are kept and reported in units of BDRV_SECTOR_S= IZE, + * so an append that would leave a write pointer at a finer granularity + * cannot be represented. Drivers may impose a coarser granularity of = their + * own, see BlockLimits.write_granularity. + */ + if (!QEMU_IS_ALIGNED(qiov->size, BDRV_SECTOR_SIZE)) { + return -EINVAL; + } + bdrv_inc_in_flight(bs); if (!drv || !drv->bdrv_co_zone_append || bs->bl.zoned =3D=3D BLK_Z_NON= E) { co.ret =3D -ENOTSUP; --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538819; cv=none; d=zohomail.com; s=zohoarc; b=lnJyhNZdFEprJk4tXdw4LHl6sxYkQXSOPbKd3hvEp6NE8t3eVkN++IkK7yGFLsALhfcbF3UMzb9x3mJuagNnSilxDeH7PvxkCKaNfHOry01agxldmmYlrWFMxFT8BPyVmvuYmoUe6sOU2FKhf6grDPxe0OW2VkYhn67ntBPx8/4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538819; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=Yx5C83lxttjo1xtPxd6rW3sYU8fSUcmNaIoE8qmQGdE=; b=AIzZectqA7TYAhtAtcTzAKDoIn8pHk9MjaHUu+hPrX2vuSkHVjjkPJeLq/Wh/Jdt2p2HnniSDdIQ9sdvqzENnv3COhyutMTev1Tvf6fTYTnT4KZd6YgA94CjSmoqDGYRE8kozKFDrd3i6ycZ7tvA5SCsXF64ed6PUF24CYumj/Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538819287456.85383585571105; Fri, 4 Sep 2026 09:20:19 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2Wcd-0000q4-C2; Fri, 04 Sep 2026 12:18:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wcb-0000pB-Fp; Fri, 04 Sep 2026 12:18:33 -0400 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2WcZ-0001Qi-RF; Fri, 04 Sep 2026 12:18:33 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 5767E41297; Fri, 4 Sep 2026 16:18:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 603DE1F00A3E; Fri, 4 Sep 2026 16:18:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538710; bh=Yx5C83lxttjo1xtPxd6rW3sYU8fSUcmNaIoE8qmQGdE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Ren8vQ5PNmc8dUQMTnCyy9kFExH5XQliK//Hrvd/n8fTyO37j+fnFUExc0fkaVvbR 6+e3Ka5LYurJqqIbKVYt+psF2SI5gPE3GcVF6A9z22oFeoVV83YBwMmJSoLsfCI+d+ wb1x5WOBtkqOe2zkITt/tLQiS/ysRwuRBSzlJL1mv8gkIGHpU6dcqenCm4EfEz69AD DwATr8kq1oPPhuX4d1rdSm/Aqhbzly3WOFajEOEdLSUxiuIYlBd5WfiDcyoAsc0jm5 lHIGzqBWOl8rFJ/fQGEQs6q1EgiQ8w8GrmrDBVsyYRTUC3UlUgj5V8yGmVEjAmaTul k9Of4MkDmHPRw== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 08/12] file-posix: remove the zone append write granularity check Date: Fri, 4 Sep 2026 18:17:56 +0200 Message-ID: <20260904161801.1568841-9-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c0a:e001:78e:0:1991:8:25; envelope-from=cassel@kernel.org; helo=sea.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538822213158500 Content-Type: text/plain; charset="utf-8" The check rejects a zone append whose individual iovec lengths are not multiples of the zone write granularity. That is stricter than the constraint it is meant to enforce, which applies to the size of the request as a whole. A request whose total is properly aligned but which is split across, say, a 512 byte and a 3584 byte iovec is refused here, even though the iovec boundaries do not survive into the scatter gather list that reaches the device. Nor is the driver the right place to enforce it. The kernel and the device validate writes to a sequential zone themselves, which is why the same function already passes the request length down without comparing it against BlockLimits.max_append_sectors. The sector granularity that holds for every backend is now checked once in bdrv_co_zone_append(), and a frontend enforces the granularity it advertises to its guest. Drop the check. BlockLimits.write_granularity is now set in one place, by this driver from the zone_write_granularity queue attribute, and read in one place, by the frontend that reports it. Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/file-posix.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index 00323f7a9f..c1ac49d23d 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -3593,8 +3593,6 @@ raw_co_zone_append(BlockDriverState *bs, BdrvRequestFlags flags) { assert(flags =3D=3D 0); int64_t zone_size_mask =3D bs->bl.zone_size - 1; - int64_t iov_len =3D 0; - int64_t len =3D 0; =20 if (*offset & zone_size_mask) { error_report("sector offset %" PRId64 " is not aligned to zone siz= e " @@ -3602,20 +3600,8 @@ raw_co_zone_append(BlockDriverState *bs, return -EINVAL; } =20 - int64_t wg =3D bs->bl.write_granularity; - int64_t wg_mask =3D wg - 1; - for (int i =3D 0; i < qiov->niov; i++) { - iov_len =3D qiov->iov[i].iov_len; - if (iov_len & wg_mask) { - error_report("len of IOVector[%d] %" PRId64 " is not aligned t= o " - "block size %" PRId64 "", i, iov_len, wg); - return -EINVAL; - } - len +=3D iov_len; - } - trace_zbd_zone_append(bs, *offset >> BDRV_SECTOR_BITS); - return raw_co_prw(bs, offset, len, qiov, QEMU_AIO_ZONE_APPEND, 0); + return raw_co_prw(bs, offset, qiov->size, qiov, QEMU_AIO_ZONE_APPEND, = 0); } #endif =20 --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538801; cv=none; d=zohomail.com; s=zohoarc; b=R3ChlynPs42ylUAS+tTeQULgly/DOm3VOKgTKANcxscqvolKebOHokD9Ic6hJ4XjINSO+dErWCWqdBii/VUJZU+u/vyACY/pRb7jXUpDU1ViAh9N/Q5PGZtEvfD08x44UGhpU8X7rLTDoAAjYfsKJ6fcEvNFuQy3hVWkSmDF7yI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538801; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=+7pxwgh6LD+wSfDu1pHYn5P69cuWbxjndwby/KCvoJY=; b=l/SH8bH/Y79gObpFF1Fe45LWarHKVJePT5c2gv413HPww5wurGiM2Q3svhiuzIH8jxN8z6qpagjvRHSgUy3g528wLGwFMkVaJxxvQQYup3ypHMUm3QwLY37FNxStoFrXDbX189qJjUwLgNaCAsjKcm8n06i4N1a58GI/84kSEFc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538801607918.878201544869; Fri, 4 Sep 2026 09:20:01 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2Wce-0000qW-Uy; Fri, 04 Sep 2026 12:18:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wcd-0000q6-Kn; Fri, 04 Sep 2026 12:18:35 -0400 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wcb-0001RV-SU; Fri, 04 Sep 2026 12:18:35 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B5FFB4113F; Fri, 4 Sep 2026 16:18:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF03C1F00A3D; Fri, 4 Sep 2026 16:18:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538712; bh=+7pxwgh6LD+wSfDu1pHYn5P69cuWbxjndwby/KCvoJY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XDGExTQA79/LfAeYg4Lf5uFiVLDNqZsZXU7pqAc25xGbmd0EDMiG7FvQE60PPjdGG aVytw+0x4ITs8O9S/srQMeVJNkJEF6rPoonAowahGVscPf8PloOXfTX216gQ3pm8QA N3STuIA+OgSLoP43PLqXoM/XK8ABvAGy0Fe06COAs3xZmbug0tbrkvgy2Utm0pcunO +MEQbtjWTUn7CkRpO5tOL0ID1GeLma/IIgPp0ObWSJlZidDT6ZdbqJfRaKwKIX6/QZ P2TQktPQVrCv7JUIHSPb8u4dwp8NwnobeelUQ0M8U7Cm1bN2OyOfNkNTvxCO0HjZlr 0+0M+t/Xm6gJA== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 09/12] file-posix: base the zone append limit on the transfer limit Date: Fri, 4 Sep 2026 18:17:57 +0200 Message-ID: <20260904161801.1568841-10-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c0a:e001:78e:0:1991:8:25; envelope-from=cassel@kernel.org; helo=sea.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538804014154100 Content-Type: text/plain; charset="utf-8" The zone_append_max_bytes queue attribute is the largest REQ_OP_ZONE_APPEND that the device accepts, and Linux has no interface for issuing one from userspace: include/uapi has no such operation, and every submitter of REQ_OP_ZONE_APPEND is in the kernel. Userspace writes to a sequential zone with an ordinary write at the write pointer. That is what this driver does. raw_co_zone_append() substitutes the write pointer of the zone for the offset and hands the request to raw_co_prw(), which reaches handle_aiocb_rw_vector() and issues a plain pwritev(). The kernel never sees a zone append, so the attribute describes a limit on an operation that is never issued. Nor is it a limit that this driver runs into. The kernel splits a write that exceeds the transfer limit rather than refusing it, so a larger append succeeds: on a null_blk device whose zone_append_max_bytes is 130560, a 16 MiB append completes and advances the write pointer by 16 MiB. Reporting the attribute only understates what the driver can do, because Linux derives it as a minimum that already includes max_sectors and chunk_sectors. Report max_hw_transfer instead, the limit that governs the write the driver actually issues. There is no use in telling a guest that it may append more than the device carries in one command, and a frontend then does not have to reason about how this driver implements an append in order to bound the value it advertises. On a null_blk device with max_hw_sectors_kb of 127 and zone_append_max_bytes of 130560, virtio-blk reports 255 sectors before and after. Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/file-posix.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index c1ac49d23d..0e92ff8414 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -1488,10 +1488,15 @@ static void raw_refresh_zoned_limits(BlockDriverSta= te *bs, struct stat *st, } bs->bl.nr_zones =3D ret; =20 - ret =3D get_sysfs_long_val(st, "zone_append_max_bytes"); - if (ret > 0) { - bs->bl.max_append_sectors =3D ret >> BDRV_SECTOR_BITS; - } + /* + * raw_co_zone_append() carries out an append as an ordinary write at = the + * write pointer, so the zone_append_max_bytes attribute, which bounds= an + * operation that this driver never issues, does not apply. The kernel + * splits a write that is larger than the transfer limit rather than + * refusing it, but there is no use in telling a guest that it may app= end + * more than the device carries in one command. + */ + bs->bl.max_append_sectors =3D bs->bl.max_hw_transfer >> BDRV_SECTOR_BI= TS; =20 ret =3D get_sysfs_long_val(st, "zone_write_granularity"); if (ret >=3D 0) { --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538756; cv=none; d=zohomail.com; s=zohoarc; b=iurD3Y8/WdM6oIEYxXxm5/cQxu7cZZmqO6oj8GqDTYKdU5xV64WZzVtdhmmTAPYDABzHbGA0wYZpNO4vGJh2dbjYf0uXx71uPtob4NB5f7Il1B0Tys2/gMpKjSw7rkM2TJ1nK9/h5j3ELzvWWusMEGjQdgTvw4cXLi97ONtiypg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538756; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=INhRDGryIWAEOCUCswXAzB5E6RNbqQ307E4XesVgWxU=; b=fe7fBL6lQyoYI1bCZSx95+sz5ltYihywuMobv6zkIIM5O1THElJt75tOxb7W6EPQoyOSpRhXHewxHm3TLcHSCRd4/VLdpzMBkEmdlw+0KnU+/BrJgiQ7rZsGK3xUj/V1oJ4//2+I1h1BzASQAG2N9sq3/23ZgoJtsf7pDehhhM4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 178853875678593.78166173581076; Fri, 4 Sep 2026 09:19:16 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2Wck-0000yp-8J; Fri, 04 Sep 2026 12:18:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wcg-0000tB-Ag; Fri, 04 Sep 2026 12:18:38 -0400 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wce-0001S1-EV; Fri, 04 Sep 2026 12:18:38 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4EC9E41297; Fri, 4 Sep 2026 16:18:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29A0A1F00A3D; Fri, 4 Sep 2026 16:18:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538715; bh=INhRDGryIWAEOCUCswXAzB5E6RNbqQ307E4XesVgWxU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YVnVE7InIOp2BJ8ZWF/P/Q4hqY8tUs730icyTTkwe0cvkShs/EjZSf9H4vj9NvkE5 Znf+GIsYAZdK+9J/b8xCydnwgoMm5lZJcJftRp35gNnJ1ie3EAnYnerZSPSpVYRFw0 2x69HVzn+D/fcqxP9/3lhU4jD7rddBBmUnXrOje7IqHZc8NU75shD2yYC06gljGq0k 5nPS09/3c4SvFyKLOZ8i/Dl1YOkHmt8dHs0QMAc5jfHNnIM/nAIZ5QzVYsqsDOs0u5 xgteypmCaA37JuoxkijuOVXMk0h4sNCyyPCaluBgh7lJBWdJIrSceBwrRx6TSc6vwg kqhsHLF7wu2LA== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , "Michael S. Tsirkin" , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 10/12] virtio-blk: derive the maximum zone append size Date: Fri, 4 Sep 2026 18:17:58 +0200 Message-ID: <20260904161801.1568841-11-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=2600:3c0a:e001:78e:0:1991:8:25; envelope-from=cassel@kernel.org; helo=sea.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538760313158500 Content-Type: text/plain; charset="utf-8" The max_append_sectors field of virtio_blk_zoned_characteristics must be set by the device to the largest zone append request that can be issued to it, and a value of zero tells the guest driver that zone append is not supported at all (virtio 1.4, 5.2.5.2). Linux refuses to attach a zoned device that reports zero. We pass BlockLimits.max_append_sectors straight through, which makes that field mean "zone append unsupported" when it is unset, rather than "this backend imposes no limit of its own". Only a backend that has a limit of its own has anything to put there. Derive the value instead. A backend limit is honoured when there is one, and otherwise the request is bounded by the zone size, since an append cannot cross a zone boundary, and by the largest request the block layer can carry. The result cannot be zero. A backend that carries out an append itself, rather than passing it to a device that has a limit of its own, is the one that knows how large a request its implementation can take, so it reports that in BlockLimits.max_append_sectors and this does not have to guess at it. Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- hw/block/virtio-blk.c | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index c2acf59c6d..131516a167 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -525,6 +525,27 @@ typedef struct ZoneCmdData { }; } ZoneCmdData; =20 +/* + * The maximum zone append data size that the device reports to the driver= in + * virtio_blk_zoned_characteristics, in 512 byte sectors. + * + * A backend that has no limit of its own leaves BlockLimits.max_append_se= ctors + * at zero, in which case the limit is whatever else bounds the request: an + * append cannot cross a zone boundary, and the block layer cannot carry a + * larger one. The result is never zero, which the driver would read as zo= ne + * append not being supported at all. + */ +static uint32_t virtio_blk_max_append_sectors(VirtIOBlock *s) +{ + BlockDriverState *bs =3D blk_bs(s->blk); + uint64_t sectors; + + sectors =3D MIN_NON_ZERO(bs->bl.zone_size >> BDRV_SECTOR_BITS, + bs->bl.max_append_sectors); + + return MIN_NON_ZERO(sectors, BDRV_REQUEST_MAX_SECTORS); +} + /* * check zoned_request: error checking before issuing requests. If all che= cks * passed, return true. @@ -560,12 +581,8 @@ static bool check_zoned_request(VirtIOBlock *s, int64_= t offset, int64_t len, return false; } =20 - if (len / 512 > bs->bl.max_append_sectors) { - if (bs->bl.max_append_sectors =3D=3D 0) { - *status =3D VIRTIO_BLK_S_UNSUPP; - } else { - *status =3D VIRTIO_BLK_S_ZONE_INVALID_CMD; - } + if ((len >> BDRV_SECTOR_BITS) > virtio_blk_max_append_sectors(s)) { + *status =3D VIRTIO_BLK_S_ZONE_INVALID_CMD; return false; } } @@ -1313,7 +1330,7 @@ static void virtio_blk_update_config(VirtIODevice *vd= ev, uint8_t *config) virtio_stl_p(vdev, &blkcfg.zoned.write_granularity, blkconf_zone_write_granularity(conf)); virtio_stl_p(vdev, &blkcfg.zoned.max_append_sectors, - bs->bl.max_append_sectors); + virtio_blk_max_append_sectors(s)); } else { blkcfg.zoned.model =3D VIRTIO_BLK_Z_NONE; } --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538789; cv=none; d=zohomail.com; s=zohoarc; b=Fgz7kVXGIvhbhvk5CKBbFtWxW7ao4dEy7jk9BYITsTo1xwHvfmjmLbkHMVKgYa0g2IlCrVkFrXJR0p4TR7sEWg6rb+AJf/mS4iNDUg5h2F/GxNygWhF5Tv9lwFlE4hsZq2DQWGZF43IhzODfa7dwgACrq64DE70a+HVBZ9mMoKE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538789; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=IAylABn7oLGfAoGAzMO/VfimbEFQhqIDJ1ttcIrqSqM=; b=ayV1tMP2wjJntiIAE+Dhh4t0B+g33bzxetgIF0dg/XtxSEZN09+G+TZlHCsOPDIS8J7cExFalwen3fJcgFEhfQf1GpqN8f9ol3CfcaAgrRkB5K1rvlyc6ryHJkaDefiPuCm2zM2z2BHgpT6me/F4k2/SBFTRGAnxpAdhYzpBpj4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538789566334.0742223353494; Fri, 4 Sep 2026 09:19:49 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2Wcl-00011V-J6; Fri, 04 Sep 2026 12:18:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wci-0000xH-JT; Fri, 04 Sep 2026 12:18:41 -0400 Received: from tor.source.kernel.org ([172.105.4.254]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wch-0001Se-3a; Fri, 04 Sep 2026 12:18:40 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id DE4ED6020A; Fri, 4 Sep 2026 16:18:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B60671F00A3D; Fri, 4 Sep 2026 16:18:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538717; bh=IAylABn7oLGfAoGAzMO/VfimbEFQhqIDJ1ttcIrqSqM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ZpeLS95gnl0vl4Z6vl9htRsOg/eEDdXHRGMEEIZke52frp7v6zExjWpqqjnPWBqSS aUxLA5W3kVEDl0q0XIUQxlO1kltdmGt9/VQsCfveLJpXc7SKmgtv2Vo8vnNpvV1tUM PrwjjcvPZe4nlkL/WZ7IgPtgQFcmzAUGnQoQ68OGD3+6NO1+G6oo8URnyifByNhicb PkvCzO0XD/3i8uuApybWlKHTHaI00SZAR3eJuDdiLCE/xnCbqf/IExh4FS0hpmnw4F Cs07DUWSANpx4ON7QJDhNW18g69OZJEza7vIVYlbfjFjgmKIXrSQedMUSk08kgsvbz KPEbzvDtZ0NNg== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 11/12] file-posix: reject a zone append past the device capacity Date: Fri, 4 Sep 2026 18:17:59 +0200 Message-ID: <20260904161801.1568841-12-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=172.105.4.254; envelope-from=cassel@kernel.org; helo=tor.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538799918158500 Content-Type: text/plain; charset="utf-8" raw_co_zone_append() checks that the offset it is given is aligned to the zone size, but not that it names a zone of the device. raw_co_prw() then derives a zone index from it and reads that entry of the write pointer array, so an offset past the end of the device reads past the end of the array. bdrv_co_zone_append() does not catch it either: bdrv_check_qiov_request() bounds the request against BDRV_MAX_LENGTH, which has nothing to do with the size of this device. A guest cannot reach it, because check_zoned_request() in virtio-blk rejects an out of range offset first, but qemu-io and any other caller of blk_co_zone_append() can: $ qemu-io --image-opts -n driver=3Dhost_device,filename=3D/dev/nullb0 \ -c "zap -p 0x100000000000 0x1000" Segmentation fault On a null_blk device with 1000 zones of 256 MiB, that offset yields zone index 65536 and reads 512 KiB beyond an 8000 byte allocation. Reject an offset that lies outside the device. That also bounds the zone index that raw_co_prw() derives from it, so its write pointer lookup stays inside the array. Fixes: 4751d09adcc3 ("block: introduce zone append write for zoned devices") Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/file-posix.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/block/file-posix.c b/block/file-posix.c index 0e92ff8414..0e8ffe91c4 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -3597,8 +3597,15 @@ raw_co_zone_append(BlockDriverState *bs, QEMUIOVector *qiov, BdrvRequestFlags flags) { assert(flags =3D=3D 0); + int64_t capacity =3D bs->total_sectors << BDRV_SECTOR_BITS; int64_t zone_size_mask =3D bs->bl.zone_size - 1; =20 + if (*offset >=3D capacity) { + error_report("*offset %" PRId64 " is equal to or greater than the " + "device capacity %" PRId64 "", *offset, capacity); + return -ENOSPC; + } + if (*offset & zone_size_mask) { error_report("sector offset %" PRId64 " is not aligned to zone siz= e " "%" PRId64 "", *offset / 512, bs->bl.zone_size / 512); --=20 2.55.0 From nobody Sat Sep 26 20:50:44 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788538810; cv=none; d=zohomail.com; s=zohoarc; b=KNp0ZLwT6XdcsOmHmWQuxnG7jWPe40ur3N85Qogkndh+WK57TUUC4T0fqGPnxHGjjJNgspVa+XAD9VPPKKFM1FBn/shLXthA9++oeBI4kFsWRE+4sP/nj1jiQCgdGW23MQxTXSZ0uMkAP/A+sGzxoazbffXaqcTNb+BPHd1GLEU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788538810; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=KSimXiGvv2sXCAqBPtLeCa7VJnYdKm5JKdHB/QGuEYg=; b=n4nzMscKLjigOlutY6xzbhA0cQKfGlIbvgBiAEX9d4BY0HwwwFYwkm9jZZYdiQN/YuxDrHG+f8K9EXaukYe0D4WGSPoX5xhCapfWec7bP0JE1JBt1B8viw1qKucSIuS7qWUeABvBUHc1vu2NMvKrrVxSpXvrw50Yrh1+sBNoT5o= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1788538810012379.11862482171296; Fri, 4 Sep 2026 09:20:10 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x2Wcm-00013H-Tu; Fri, 04 Sep 2026 12:18:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wcl-00012T-NP; Fri, 04 Sep 2026 12:18:43 -0400 Received: from sea.source.kernel.org ([172.234.252.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x2Wcj-0001Tb-Mj; Fri, 04 Sep 2026 12:18:43 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4F2AA405D7; Fri, 4 Sep 2026 16:18:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29EE31F00A3D; Fri, 4 Sep 2026 16:18:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788538720; bh=KSimXiGvv2sXCAqBPtLeCa7VJnYdKm5JKdHB/QGuEYg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ArNNcfqQmtleP3qCQNzZziqNR8f4IWPfmSYTnK16v5X8PgiuHaz2jUp3MqL7UZJud NcQsggvSwrwS+GJEJFw1qiTYNQwP3xWSOwWxuBOvSUWAS6FRys+NQtdh+6s5A4JMbe OzHQNoV/8aQcskJIeYqtvXee255EjcLjUIFo02Yga/7QJtGqbimlp0mZyaHd8rrxPj b1AaTR09f5WZRCBXGJ/qrYsZeGM2WwmRYCkmkxONy5XS5YVBqGGWvNJNhrVV/w6/ba fdrUSLo2SxufdnZCGQ6932PwITpvWFIAlQ7uROtb+6XTx8T9qfS44BNJSpPkGl6b8Q fqwnP6iOC0Y/g== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Hanna Reitz , Fam Zheng Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v3 12/12] file-posix: reject a zone append to a full or conventional zone Date: Fri, 4 Sep 2026 18:18:00 +0200 Message-ID: <20260904161801.1568841-13-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260904161801.1568841-1-cassel@kernel.org> References: <20260904161801.1568841-1-cassel@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=172.234.252.31; envelope-from=cassel@kernel.org; helo=sea.source.kernel.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788538811992154100 Content-Type: text/plain; charset="utf-8" raw_co_prw() replaces the offset of a zone append with the write pointer of the addressed zone, which assumes that the stored value names a position inside that zone. It does not in two cases. A full zone has its write pointer recorded at the end of the zone, since get_zones_wp() stores start + len for BLK_ZONE_COND_FULL. That is the first sector of the following zone, so the append is submitted there. The kernel accepts it whenever that zone is empty, because it is a legal write at its write pointer, and the completion path advances the wrong zone because it recomputes the zone index from the replaced offset. The data is written to a zone that was never addressed and success is returned: zone 2 finished, then a 4 KiB append to zone 2: After zap done, the append sector is 0x180000 <- zone 3 zone 2: wptr 0x180000, zcond:14 (full) zone 3: wptr 0x180008 <- advanced A conventional zone has no write pointer at all, and its array entry carries only the type marker in the top bit, so the offset becomes negative and the write fails with EINVAL. That is harmless but it reports nothing about the actual mistake. Reject both while the write pointer lock is held, since the state has to be read and acted on atomically. check_zoned_request() in virtio-blk refuses an append to a conventional zone, so that case needs a caller that goes to the driver directly, but nothing there examines whether a zone is full, so a guest can reach the misdirected write. Fixes: 4751d09adcc3 ("block: introduce zone append write for zoned devices") Signed-off-by: Niklas Cassel --- block/file-posix.c | 27 +++++++++++++++++++++++++-- block/io.c | 9 +++++++++ include/block/block-io.h | 6 ++++++ 3 files changed, 40 insertions(+), 2 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index 0e8ffe91c4..2cd16f58a2 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -2565,8 +2565,31 @@ raw_co_prw(BlockDriverState *bs, int64_t *offset_ptr= , uint64_t bytes, bs->bl.zoned !=3D BLK_Z_NONE) { qemu_co_mutex_lock(&bs->wps->colock); if (type & QEMU_AIO_ZONE_APPEND) { - int index =3D bdrv_zone_index(bs, offset); - offset =3D bs->wps->wp[index]; + uint32_t index =3D bdrv_zone_index(bs, offset); + uint64_t wp =3D bs->wps->wp[index]; + + /* + * The write pointer of the addressed zone becomes the offset = of + * the write, so it has to name a position inside that zone. It + * does not for a conventional zone, which has no write pointe= r and + * stores a type marker in the top bit instead, and it does no= t for + * a full zone, whose write pointer is reported at the zone en= d. + * Either would send the data to a zone that was never address= ed. + */ + if (BDRV_ZT_IS_CONV(wp)) { + error_report("zone append at offset 0x%" PRIx64 " addresse= s a " + "conventional zone", offset); + qemu_co_mutex_unlock(&bs->wps->colock); + return -EINVAL; + } + if (bdrv_zone_is_full(bs, index)) { + error_report("zone append at offset 0x%" PRIx64 " addresse= s a " + "full zone", offset); + qemu_co_mutex_unlock(&bs->wps->colock); + return -ENOSPC; + } + + offset =3D wp; } } #endif diff --git a/block/io.c b/block/io.c index b59c7fdf3e..452254bc63 100644 --- a/block/io.c +++ b/block/io.c @@ -3378,6 +3378,15 @@ uint32_t bdrv_zone_index(BlockDriverState *bs, uint6= 4_t offset) return offset >> ctz64(bs->bl.zone_size); } =20 +bool bdrv_zone_is_full(BlockDriverState *bs, uint32_t index) +{ + uint64_t zone_end =3D MIN((uint64_t)(index + 1) * bs->bl.zone_size, + (uint64_t)bs->total_sectors << BDRV_SECTOR_BIT= S); + IO_CODE(); + + return bs->wps->wp[index] >=3D zone_end; +} + void *qemu_blockalign(BlockDriverState *bs, size_t size) { IO_CODE(); diff --git a/include/block/block-io.h b/include/block/block-io.h index 71c8cdf2e1..8514db648c 100644 --- a/include/block/block-io.h +++ b/include/block/block-io.h @@ -131,6 +131,12 @@ int coroutine_fn GRAPH_RDLOCK bdrv_co_zone_append(Bloc= kDriverState *bs, * zone size that is a power of two, so the division is a shift. */ uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_t offset); +/* + * True when the write pointer of a zone has reached the end of the writab= le + * part of that zone, so that nothing more can be written to it until it is + * reset. The write pointer lock must be held when called. + */ +bool bdrv_zone_is_full(BlockDriverState *bs, uint32_t index); =20 bool bdrv_can_write_zeroes_with_unmap(BlockDriverState *bs); =20 --=20 2.55.0