From nobody Sat Sep 26 19:59:36 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=1789752632; cv=none; d=zohomail.com; s=zohoarc; b=Y7JiacKzv8c00nATokavhXR5e8J9y69l/Zto7Tv/ZEXERP8K6MTeM6BxP13peVPNgtV6cHrjKfdZA+3ISRqgt9a65tssMKONwGYI/cqAXbgx59FWk2LuKBOvmZ2asAr1lBeFtxQgJTQCfYVao/3HvdtobqgbEQ981Rdsn8dzbFI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752632; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=TO+F2pc2vn4cH6gj+eUGA+TbOU46rfxX7z+qzRTHsOk=; b=jhbq+xB9OkgW4vVwKZSdJKsaNiesq2zSbFqRDJf4S+GunpapxPWzBlrdhp9NckjXcaHab/8jyE0aMjkI91rgCH7HXBuNnOCrmThkUozhlmGamq0YFvWr1LpzHVTix15as3KCu8x16m4acGzPXC63P5wgOjLF0gfb0xEl41Ocpng= 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 17897526320971016.3193869085551; Fri, 18 Sep 2026 10:30:32 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPI-0004Zr-Qy; Fri, 18 Sep 2026 13:29:54 -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 1x7cP7-0004Yu-TU; Fri, 18 Sep 2026 13:29:41 -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 1x7cP6-0000GG-9p; Fri, 18 Sep 2026 13:29:41 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 669FE60A55; Fri, 18 Sep 2026 17:29:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45ACE1F000FF; Fri, 18 Sep 2026 17:29:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752578; bh=TO+F2pc2vn4cH6gj+eUGA+TbOU46rfxX7z+qzRTHsOk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=CHk5vSnA/vTHa+s5khICf2zOKAI9wWhe7P0BAGvwVsT43fL4u2jamcbmxE1VaILyp b1W6sd6wAq4BruUWPBUPjyJzls16e3DfPrF7gCrO1dBhtLXE/RrI4ZXn37fKiaZ3we bWP8bJDvyFaCK3EPzrnUzW22ARfq8Z7rjSOYSI+HZnipHOWHMxzcWe/PdZmQc8apWH gGyc5kC0R2mNDYtwcn7ZLqqVCW6sAnE0zyBH+ECP5/FiTyAGOq/lX1SBDMSw9Y2yet 0Avmd+KHRYLb9KUHPqggS3bO+B5GZpIszbhIo7aiSrbcQm63v0oh1xmIP0CVjh9cTy RSiuy10LLFjFw== 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 v5 01/15] block: widen BlockLimits.zone_size to uint64_t Date: Fri, 18 Sep 2026 19:29:09 +0200 Message-ID: <20260918172925.2640888-2-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752634018158500 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 19:59:36 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=1789752766; cv=none; d=zohomail.com; s=zohoarc; b=It3UOChLdWxTq5xmeihLbszjdQxhdHIiqZQgBAEK3ka+ZvaujcS9AojAMRId/LNxUJrERHb6LjhPAgiUVLNCD1iy4eHmE//5s6OKq6rBOXOpP7xa8vCCifrFj8aXPaBZcr4NJi++J8zTb8D5u0t3qzkLKkdRIWXdHMLgIXuf8SE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752766; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=73VXbOmIWKrxxbLYFyatApK8x2l7ryOhTMdeyx8DgzQ=; b=F+YNNMHc61GOq4tPV78F7tF/7aVDv1ZY/GDevdkeBXWd6J8UgFAcu7+qW8rhPukdHvMuNYw5X0h+OeRUbzjJBrdY/Yq2qZtrfudP7OBR8OJBYQEpwi00csXx2jZJcSOr8GH+lbi/xD5Ze5VirgJWlsZr729rkca7Xt5lUPeu8GA= 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 1789752766916345.0211272875705; Fri, 18 Sep 2026 10:32:46 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPs-0004tQ-Cr; Fri, 18 Sep 2026 13:30: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 1x7cP9-0004ZJ-Pw; Fri, 18 Sep 2026 13:29:43 -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 1x7cP8-0000GS-06; Fri, 18 Sep 2026 13:29:43 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id CA51640951; Fri, 18 Sep 2026 17:29:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7C261F000FF; Fri, 18 Sep 2026 17:29:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752580; bh=73VXbOmIWKrxxbLYFyatApK8x2l7ryOhTMdeyx8DgzQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=B1xqUa0Q5xX4wdDLruTlKty31dH9mWK5W6JJiy8BpSG1FYDOy4sVAId/EBi2by4g0 xSd5Z8L0AADk9OduLaJtKY6I7KsrnoW5O377Nlx+vKrHn/gl71sECtb1WuYQkkEcWf ScqbYy/Svst4UFi2YaNyedk8ajiQgOdGISrcf7K8vBKuR4e6AlG9T4ZOU4a4sPKmBU se7eZm1WnaQ4mRW/Y1oQf/hcSZz6WmP5pRsS0qIQ9TjgkmCBZ5gjAQQi1drwwIngJq kLOxxwiOVbA1GTn3d/L0gf3PWXG6X6PtKKnhPVudZkv4dK+3Ss2UrtIAT/1o9GCPB+ +pyuicsDMpV0A== 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 v5 02/15] virtio-blk: do not merge requests across a zone boundary Date: Fri, 18 Sep 2026 19:29:10 +0200 Message-ID: <20260918172925.2640888-3-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752768639158500 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 61c341ce2c..1b93364b24 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -288,6 +288,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); @@ -303,17 +306,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 19:59:36 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=1789752794; cv=none; d=zohomail.com; s=zohoarc; b=eTy5I65ttpi6+AuW/LtWEZNB5fcnv7c/Gt4XB1ompB4IqCHgAqL/X/yk952vebQgHJa9jIbmmi89l1QHZmO5qec9lS5to05v+TKB6AUk/3qQ/47asuh1ejdFFQPT1EcQHaG10BHvSukRrPt1khVzHcsqZ1TLdLBzue4oRBbXHcU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752794; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=r4pQbb7stqN5koXvzUoBxkiXWQPhpFT8DfoDGXIJxgk=; b=Epnz3/LYRdozzTB5UYYKVgL9jSp2JowCGmGvZT8qD7T05RITFodsSpGotGMxTM8jzcBaatQyVuKY1FI9oXp7CF/2m8HgtK/FS3JjLK7mXssvFyBIuPzP7iMhjWqAZ50jrYTseQ/7s99DKJBOKbTDWfHL6bffMqfafbndyCoEUi0= 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 1789752794191102.79846535164666; Fri, 18 Sep 2026 10:33:14 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPa-0004cv-4k; Fri, 18 Sep 2026 13:30:10 -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 1x7cPD-0004Zt-6q; Fri, 18 Sep 2026 13:29:49 -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 1x7cPA-0000Gt-Q3; Fri, 18 Sep 2026 13:29:46 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 9BC4640951; Fri, 18 Sep 2026 17:29:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B8D01F000FF; Fri, 18 Sep 2026 17:29:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752583; bh=r4pQbb7stqN5koXvzUoBxkiXWQPhpFT8DfoDGXIJxgk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YhkKJ/bM9zoEqsAj6YKWPC9Tza4ig/ecJbZe5Hf9keV15YOLn5156JjdRYZbz8OGS 0GubZh+GgGvRp89LmXekTWtMLlOYE7gjoFuZ9YQD5TMoPxM46FC71cfJ8dz8Qgd85c gx2/+TrTyNHXaYazeBbE27OpXQGwAlyUvmrsIanH5kADIbam2f7Xe/pTCnUEFwm+xf 4Ytb9AhmiWe0gPWWTIEyhpPZti7x17P0ag00GNHF5VYAAewpVWu4un0fbQSw8Qxkx1 V3BqHil/XSsjiFy9I2pESSjxSasxu9vQXnY7i+QRwfhlNytzJUFvz6DdcT/ApfYWS6 2Kz3irJk26u2Q== 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 v5 03/15] block: add a helper for the index of the zone an offset falls in Date: Fri, 18 Sep 2026 19:29:11 +0200 Message-ID: <20260918172925.2640888-4-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752794787158501 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. Linux requires that of every zoned device it accepts, in blk_revalidate_disk_zones() and in each of the drivers that report one, and qcow2 rejects an image whose header says otherwise. So the division is a shift, and the shift is worth deriving once rather than at every use: record it in BlockLimits as zone_size_bits, next to the size it comes from, and assert the property that it relies on where it is computed. 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. Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/file-posix.c | 8 ++++---- block/io.c | 12 ++++++++++++ hw/block/virtio-blk.c | 2 +- include/block/block-io.h | 2 ++ include/block/block_int-common.h | 7 +++++++ 5 files changed, 26 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..cef23ee5bc 100644 --- a/block/io.c +++ b/block/io.c @@ -227,6 +227,11 @@ void bdrv_refresh_limits(BlockDriverState *bs, Transac= tion *tran, Error **errp) } } =20 + if (bs->bl.zone_size) { + assert(is_power_of_2(bs->bl.zone_size)); + bs->bl.zone_size_bits =3D ctz64(bs->bl.zone_size); + } + if (bs->bl.request_alignment > BDRV_MAX_ALIGNMENT) { error_setg(errp, "Driver requires too large request alignment"); } @@ -3361,6 +3366,13 @@ out: return co.ret; } =20 +uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_t offset) +{ + IO_CODE(); + + return offset >> bs->bl.zone_size_bits; +} + 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 1b93364b24..6e4a7a4076 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -523,7 +523,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..9d1c0eb7fb 100644 --- a/include/block/block-io.h +++ b/include/block/block-io.h @@ -126,6 +126,8 @@ int coroutine_fn GRAPH_RDLOCK bdrv_co_zone_append(Block= DriverState *bs, int64_t *offset, QEMUIOVector *qiov, BdrvRequestFlags flags); +/* The index of the zone that @offset falls in. */ +uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_t offset); =20 bool bdrv_can_write_zeroes_with_unmap(BlockDriverState *bs); =20 diff --git a/include/block/block_int-common.h b/include/block/block_int-com= mon.h index 7571ed9968..82aa0c1a6e 100644 --- a/include/block/block_int-common.h +++ b/include/block/block_int-common.h @@ -903,6 +903,13 @@ typedef struct BlockLimits { /* zone size expressed in bytes */ uint64_t zone_size; =20 + /* + * log2 of zone_size, derived by bdrv_refresh_limits(). A zoned device + * always has a zone size that is a power of two, so the zone an offset + * falls in is a shift rather than a division. See bdrv_zone_index(). + */ + uint32_t zone_size_bits; + /* total number of zones */ uint32_t nr_zones; =20 --=20 2.55.0 From nobody Sat Sep 26 19:59:36 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=1789752668; cv=none; d=zohomail.com; s=zohoarc; b=Kk6+2jL5gsq5sanftEexkKzjuZvqZaXaznrEWerEM1Plles2Onlbl4K3D+XhEzyhnSdDge3ujbU9A92SEUGIAPmC5PRH3nJkr5fxU3zoIPqH8k7tMS7h+Wd6w+o9eVWUnVrAfGEYaOI1sdGtKIYAL/cHhN2aCekdVFiJNX7GMjs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752668; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=PTZ+yrhR+/MJNKDSkwD+F+glze+MmD3SwdgrHQBQnJY=; b=D2/5fZviYZROFiYijPwccESZQt4esHkq9ssa9yxq86K5m9IVbbvcy0rLTKMkMqNpKNPFMPhhzNhnCjIz/lu1l4Bq3G6k3kaG2uAJHrv6EyiRqRyMQP2SKgkDOdBeeAtwUMVbTtI/qNgzQZIzg2gGrxTyrrHSgTJ9xyrucGPDj3E= 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 1789752668228258.7726181703681; Fri, 18 Sep 2026 10:31:08 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPm-0004r7-8C; Fri, 18 Sep 2026 13:30: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 1x7cPF-0004aD-8f; Fri, 18 Sep 2026 13:29:51 -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 1x7cPD-0000HC-JM; Fri, 18 Sep 2026 13:29:49 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 6724240300; Fri, 18 Sep 2026 17:29:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 157DA1F000FF; Fri, 18 Sep 2026 17:29:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752586; bh=PTZ+yrhR+/MJNKDSkwD+F+glze+MmD3SwdgrHQBQnJY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=VYykcODu91aRVGoP8q7+ocGiFW2SKYYOsQ7SJVDAFp/vZctWQ/VSsBPvq40FMiJ0p pa7ZKEIX24pOi9/8dD0yumDolWdZYvut/ixZqo/1iMP2loXoUeojeg9JnZO4n3nX7L NV4YTDT/nt1szA5SGdmbqC3tG6X9hF+T9NmoARw8V1QpwBvMgOdewp+whKrF/zdXzV Fz/H8YSR/ApkM1UW0ArV1X6pflPZDQ3Yr09QOBFhE9uTDu879w7naF65H8sZsz1lZy oPbbcKklK5MnT5JimwbueP7P12Ecrqr3RVHJndT0B8YsBKHowOp+Filglb43XHSMSF D5vV0EI94TCkg== From: Niklas Cassel To: Stefan Hajnoczi , Kevin Wolf , Fam Zheng , Hanna Reitz , "Michael S. Tsirkin" Cc: Sam Li , Damien Le Moal , Niklas Cassel , qemu-block@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v5 04/15] block: add a helper to check if a zone is conventional Date: Fri, 18 Sep 2026 19:29:12 +0200 Message-ID: <20260918172925.2640888-5-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752670151158500 Content-Type: text/plain; charset="utf-8" Whether a zone is conventional is encoded in the most significant bit of the write pointer that the block layer keeps for it, so a caller that wants to know has to reach into bs->wps->wp[] and apply BDRV_ZT_IS_CONV() to the raw value. virtio-blk does that, which means a device model both knows how a block driver stores its write pointers and knows what one of the bits of a write pointer means. Add an accessor next to bdrv_zone_index() and use it there, so that the encoding stays with the code that chose it. Unlike bdrv_zone_is_full(), this does not need the write pointer lock. get_zones_wp() only ever sets the bit for a conventional zone and never clears it, and a zone does not change type, so the answer cannot become stale. The rest of the word does change, on every write, which is what the lock is there for. Signed-off-by: Niklas Cassel --- block/io.c | 7 +++++++ hw/block/virtio-blk.c | 2 +- include/block/block-io.h | 6 ++++++ 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/block/io.c b/block/io.c index cef23ee5bc..da61e641ac 100644 --- a/block/io.c +++ b/block/io.c @@ -3373,6 +3373,13 @@ uint32_t bdrv_zone_index(BlockDriverState *bs, uint6= 4_t offset) return offset >> bs->bl.zone_size_bits; } =20 +bool bdrv_zone_is_conv(BlockDriverState *bs, uint32_t index) +{ + IO_CODE(); + + return BDRV_ZT_IS_CONV(bs->wps->wp[index]); +} + 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 6e4a7a4076..dd69d81532 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -524,7 +524,7 @@ static bool check_zoned_request(VirtIOBlock *s, int64_t= offset, int64_t len, } =20 index =3D bdrv_zone_index(bs, offset); - if (BDRV_ZT_IS_CONV(bs->wps->wp[index])) { + if (bdrv_zone_is_conv(bs, 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 9d1c0eb7fb..e469df7061 100644 --- a/include/block/block-io.h +++ b/include/block/block-io.h @@ -128,6 +128,12 @@ int coroutine_fn GRAPH_RDLOCK bdrv_co_zone_append(Bloc= kDriverState *bs, BdrvRequestFlags flags); /* The index of the zone that @offset falls in. */ uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_t offset); +/* + * True if the zone at @index is a conventional zone, which can be written + * anywhere in any order. The type of a zone does not change, so unlike + * bdrv_zone_is_full() this does not need the write pointer lock. + */ +bool bdrv_zone_is_conv(BlockDriverState *bs, uint32_t index); =20 bool bdrv_can_write_zeroes_with_unmap(BlockDriverState *bs); =20 --=20 2.55.0 From nobody Sat Sep 26 19:59:36 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=1789752801; cv=none; d=zohomail.com; s=zohoarc; b=B/4YjkhKVxUAr4BMNwUfGsthUmb+zscksuHN8hhUvPXFepXjH3aozp68X58ObwHxwNSVntUjmP5C7CqEedp8aATBayDhdZiqrvyVD0Ju9qEMvC309ccOR0wCd3Ve+vqo0chAKXOz8wRsW8jJa0S4nAvRkwj/vMT/zLqbGU3THoc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752801; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=BaGydPCSUAeNb0eWyHPI3N0R/c7Ye/3rI6LSXHt3/po=; b=eMsLsA1nNlFyfngg8PsK58307cHnxSeHUs7GlB9q0JnVY0dNjuWxxMuhQ8cAQARV4G+byGqwNKxSNKeNCGBqjSnTvWxhFQz7+EYk8N7I+/zvhp/dMk1sAUMpUIPi1Zw2xfFKQSfmbwQ6y2drzSzYUhQXWZo6YenGSvqEEGQkpWg= 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 1789752801370845.5321820236464; Fri, 18 Sep 2026 10:33:21 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPs-0004tk-Ow; Fri, 18 Sep 2026 13:30: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 1x7cPI-0004aV-8z; Fri, 18 Sep 2026 13:29:54 -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 1x7cPG-0000HY-Gi; Fri, 18 Sep 2026 13:29:51 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 8FCE66053D; Fri, 18 Sep 2026 17:29:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D93821F000FF; Fri, 18 Sep 2026 17:29:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752589; bh=BaGydPCSUAeNb0eWyHPI3N0R/c7Ye/3rI6LSXHt3/po=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=WPijOOlBiW6mwx3Q4eMZWunDf0bg+Di90+IV2GGngToJ022j0R4w6c5dZUKA9835B 9GdoH7Z2Y+jxCDakQ/aYCjkHs6Nhw0TPCj8jMlu7la2tsaOFchrRUutHKEB5QNM1a/ uLcEvGos+OdS3NCsYvX4aec0qnzqkS6qw/GoY+o9IbWAK4tifFFiInUha0zrXwqu+8 7vZFjGgUNJroHzYzgb4e1rd7/LSAYjIJ8XFHRRJiAF92gFCnZNROreYe0IpLEf/Exy h4g1qs2b9h1m6SKTQDw/5/AtMVQrYc5gy9p4GsVWWMLCKKNF6+beF8ir6F8D+Q2rPX vLDZd3wHLj2Qg== 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 v5 05/15] hw/block: derive the zone write granularity from the block sizes Date: Fri, 18 Sep 2026 19:29:13 +0200 Message-ID: <20260918172925.2640888-6-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752805009158500 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 logical and the physical block size instead. Both are properties of the device model, so the value that a guest is given does not change when it is migrated to a host whose disks differ, which a value taken from BlockLimits would. It is also what a guest derives for itself: blk_validate_zoned_limits() raises zone_write_granularity to the logical block size, and for a SCSI disk sd_zbc_read_zones() takes it from the physical block size. blkconf_blocksizes() rejects a logical block size larger than the physical block size, so this is the physical block size in practice. It is expressed as the larger of the two because that is the constraint which applies: a guest cannot issue a write finer than the logical block size, and the medium cannot take one finer than the physical block size. Add it as a helper next to blkconf_blocksizes(), since it is derived from a BlockConf, 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") Signed-off-by: Niklas Cassel --- hw/block/block.c | 5 +++++ hw/block/virtio-blk.c | 13 +++++++------ include/block/block_int-common.h | 7 +++++++ include/hw/block/block.h | 13 +++++++++++++ 4 files changed, 32 insertions(+), 6 deletions(-) diff --git a/hw/block/block.c b/hw/block/block.c index f187fa025d..79b0a67cea 100644 --- a/hw/block/block.c +++ b/hw/block/block.c @@ -201,6 +201,11 @@ bool blkconf_blocksizes(BlockConf *conf, Error **errp) return true; } =20 +uint32_t blkconf_zone_write_granularity(BlockConf *conf) +{ + return MAX(conf->logical_block_size, conf->physical_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 dd69d81532..6bf1049aea 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -516,11 +516,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); @@ -1276,7 +1276,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/block/block_int-common.h b/include/block/block_int-com= mon.h index 82aa0c1a6e..7abd2b12bb 100644 --- a/include/block/block_int-common.h +++ b/include/block/block_int-common.h @@ -922,6 +922,13 @@ typedef struct BlockLimits { /* maximum number of active zones */ uint32_t max_active_zones; =20 + /* + * The granularity that the backend requires of a write to a sequential + * zone, in bytes, or zero if it has none. This describes the host, so= it + * must not be reported to a guest: a frontend reports + * blkconf_zone_write_granularity() and checks this against it when the + * device is realized. + */ uint32_t write_granularity; } BlockLimits; =20 diff --git a/include/hw/block/block.h b/include/hw/block/block.h index df941df19f..c769b1297d 100644 --- a/include/hw/block/block.h +++ b/include/hw/block/block.h @@ -114,6 +114,19 @@ 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. A= guest + * cannot issue a write finer than the logical block size, and the medium = cannot + * take one finer than the physical block size, so the constraint that app= lies + * is the larger of the two. A frontend must report this value to its gues= t and + * validate requests against it. + * + * It is derived from the configuration and not from the backend, so that a + * guest is not given a property of the host, which would differ after + * migration. blkconf_blocksizes() rejects a logical block size larger tha= n the + * physical block size, so this is the physical block size in practice. + */ +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 19:59:36 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=1789752753; cv=none; d=zohomail.com; s=zohoarc; b=m7+4C0E6qDMYbU6FwgsfhfCVT6Q60Io8U+cDhjTQMxTSn88BneajjBXUo2/hZZfH3zTh0sarag2DANYpV8ajjowWqUjjyMczdZe80zRn1BzsCNja/nS4kGVHUvRJmLTxw1XLbof/f7j7rktIjkY7qC8axTw6lje324r/0I0Mox4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752753; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=OgmltRd6wLig8bdrWuXMSgOtC3LvgvNQhmF8C2SSCKc=; b=LteRjNAz6Zo9z5kcjTwtaVRiI9aHFGUIRQJ5KsTlg2FvIQuh4SzqN1csS3QiOd4Q3paA8wbM/Np/Vxw3Pc3Y+SzZYHtGFnufMxjIBC7VDJVT+05+SttoelZNpC5jx6i+bybdpj8cEX3QJ9AClCQORhetR/uj7TpXExEiqIXgJz4= 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 1789752753274911.761732058556; Fri, 18 Sep 2026 10:32:33 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPs-0004th-N7; Fri, 18 Sep 2026 13:30: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 1x7cPM-0004bd-MO; Fri, 18 Sep 2026 13:29:56 -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 1x7cPJ-0000Ho-1v; Fri, 18 Sep 2026 13:29:54 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 257416053D; Fri, 18 Sep 2026 17:29:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA14F1F000FF; Fri, 18 Sep 2026 17:29:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752591; bh=OgmltRd6wLig8bdrWuXMSgOtC3LvgvNQhmF8C2SSCKc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=O4BNlH3H8mTpE57q4AOmYjOg6+aYui1RZ1Iq9rUBxa9mgEzAG89qBfLFrRsUiuqtf pWYZENTMitsE1a78X7yUcJZ9ZLCu2JgTv+96+OAgbz/RgzpAejDHtFcFmWSYQh0gy/ 2sxaKZI+57rNymNznRO6sxBGaSESF9PrDRIqwZAKdml3soex/XX2SKPqjyUT7uvwfd I6yWtXIH6SDBIc6l/MmkRlqLrUYi5cW6slVZQ5mpdjPuFZmkQA2Tz9JuYQDejAUT1G uLoRwoo3fj2/1hwluNWFB5ybjKNddrYPCAsluAuPfVxuPpePlhu4ZuiRGfajOAZ1BK HO8B1fbpWPRpA== 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 v5 06/15] virtio-blk: check the write granularity of writes to sequential zones Date: Fri, 18 Sep 2026 19:29:14 +0200 Message-ID: <20260918172925.2640888-7-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752754514158500 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. Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- 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 6bf1049aea..449de307b4 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -392,6 +392,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_zone_is_conv(bs, 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) { @@ -518,7 +545,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; } @@ -913,6 +940,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 19:59:36 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=1789752705; cv=none; d=zohomail.com; s=zohoarc; b=XxdT+xW4lUjkxCy2Xz3AMgOkSQ80PF4Zxt1ih13AL4nJugSWHPVLE2y3e8Dz/DyWWarMSR1wAScdMck+rJa79V8CBw33abqoHPBnTRezZIgT+/HUriFOdCrNWo2IjvM1rSG0RHh04F5OSh6bddVuynzITE3LMNWj4eQXCFkNoRI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752705; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=HE4fbtBVZ7BN13xy8oo7npZAX2OBj52IgG8zDIJZros=; b=Nyq80P0P02okuDVmS2+dDVjb+GVR10jNOuEgPFUVnEiaGTMrtrB8lm+5ljZceXY3+CPSzpxbhP5kLF2ypk8l1+owIJ9etIIlXtM6fDrr7CbTzLVEjCd8HgW5d0ia1sgO1B//21Gyxi3d4WVMkzMTlzjvikA8/M7h9cIOAk+18Po= 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 178975270515627.899788086398644; Fri, 18 Sep 2026 10:31:45 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPv-0004xU-AY; Fri, 18 Sep 2026 13:30: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 1x7cPO-0004cP-P1; Fri, 18 Sep 2026 13:30:00 -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 1x7cPM-0000I2-PO; Fri, 18 Sep 2026 13:29:58 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id E71684049D; Fri, 18 Sep 2026 17:29:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67DC21F000FF; Fri, 18 Sep 2026 17:29:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752594; bh=HE4fbtBVZ7BN13xy8oo7npZAX2OBj52IgG8zDIJZros=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BDy3dA0YdbqIOeEhWFWCEkv4RkP8tF3pFzp6xFfW7VCMNEEa2AP9bi8YpM99QfN/w i3ailKhcXB4fUOE50mSmQOGVKInDexdzOyeO3Pwv4CJniy0oUqifOoddwGH7Iz/CJE K5/bDzz1SNS5/5JYRZEQBUzXtIcdR9yUWQjLgy07ad8nCgMwEQ6otFJb2gmMqOZpLY WIfY599UFW9s5nHl4QNhCAF17r2IfXqGZ2RLQKdUpLpPSFZXr1GErKvZiGZmcptVlE CKp7MgyGW8K24fXBlOsOXNm+KSgfZiiz/8V1VKOml4GWqJS6SNdVlJjgJ1nJjahBwU jUlwLmRsXhthg== 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 v5 07/15] hw/block: reject a zoned device that the block sizes cannot address Date: Fri, 18 Sep 2026 19:29:15 +0200 Message-ID: <20260918172925.2640888-8-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752706330158500 Content-Type: text/plain; charset="utf-8" The write granularity that a frontend reports is derived from the logical and the physical block size, which are properties of the device model, while the granularity that the medium requires and the write pointers that it holds belong to the backend. Nothing ties them together, and where they disagree a guest is told about a device it cannot use. A backend can require a coarser granularity than the block sizes express. A 512e host managed disk has a logical block size of 512 and requires writes to a sequential zone to be a multiple of 4096, so attaching it with a finer physical block size reports a granularity that the disk will not accept, and the guest is given a plain I/O error for a request that it was told was valid. The write pointers can disagree in the same way. They outlive any particular use of the device, while the block sizes are chosen afresh every time it is attached, so a zone written with logical_block_size=3D512 leaves a write pointer that logical_block_size=3D4096 cannot address. A zone report expresses it in 512 byte sectors, so the guest is told about a position that does not fall on a logical block boundary, which it can neither read nor write, and the zone can then only be recovered by resetting it. The reverse is harmless: a pointer laid down with a larger logical block size is still a multiple of a smaller one. Check both at realize time, along with the zone size and the zone capacity, 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 --- hw/block/block.c | 63 ++++++++++++++++++++++++++++++++++++++++ hw/block/virtio-blk.c | 4 +++ include/hw/block/block.h | 1 + 3 files changed, 68 insertions(+) diff --git a/hw/block/block.c b/hw/block/block.c index 79b0a67cea..3bb8121e9e 100644 --- a/hw/block/block.c +++ b/hw/block/block.c @@ -206,6 +206,69 @@ uint32_t blkconf_zone_write_granularity(BlockConf *con= f) return MAX(conf->logical_block_size, conf->physical_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); + + /* + * A backend that requires a coarser granularity than the one that is = about + * to be reported would reject writes that the guest has been told are + * valid, leaving it with a plain I/O error. + */ + if (bs->bl.write_granularity > wg) { + error_setg(errp, "the backend requires writes to sequential zones = to " + "be a multiple of %" PRIu32 " bytes, which is coarser t= han " + "the zone write granularity %" PRIu32 " that would be " + "reported", bs->bl.write_granularity, wg); + error_append_hint(errp, "Set physical_block_size=3D%" PRIu32 ".\n", + bs->bl.write_granularity); + return false; + } + + 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; + + if (bdrv_zone_is_conv(bs, i)) { + continue; + } + + wp =3D bs->wps->wp[i]; + 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 finer z= one " + "write granularity. Reset them, or attach th= e " + "device with the block sizes that they were " + "written with.\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 449de307b4..74bd08b0ec 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -1840,6 +1840,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 c769b1297d..c0a8b84df1 100644 --- a/include/hw/block/block.h +++ b/include/hw/block/block.h @@ -127,6 +127,7 @@ bool blkconf_blocksizes(BlockConf *conf, Error **errp); * physical block size, so this is the physical block size in practice. */ 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 19:59:36 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=1789752790; cv=none; d=zohomail.com; s=zohoarc; b=Thvtq+tgFVfSKH8AvgPNCYUIY05U+rxTsGRm9WMlBCwJBHWgAaWl/VekGA+1mlwkx6DNMin2LuAqpoAkEN8omCE4/FHI0p4EmvWLJelQ3GtvtjdafBfklnQYDj6aTlWmjTWWo40EPW2EsohYdOtkw6An2E3MDvnPcj5kl8eYpxo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752790; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=vXQYAj1GDHVUV/kpueHVjpCwP39k1qM4lW2PSzvXObk=; b=At64iTsc8fqKwygv1c/vehf/xgFkqOfP1BNwkMa6mHsthZ5x+jqrVN/tlhNi965H89z7hKOvaPHFWqzoApgiVJmr7klHynzYCzsGvfnFGxj23/P2sJtUFJQo+VfJjfdkb/X7kSYuQ1rIDxyDs1xJtRean6D42AFDpD/6xVKHSmI= 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 1789752790107782.1926745076481; Fri, 18 Sep 2026 10:33:10 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPt-0004wO-Uy; Fri, 18 Sep 2026 13:30:30 -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 1x7cPQ-0004cf-37; Fri, 18 Sep 2026 13:30:02 -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 1x7cPO-0000IX-LC; Fri, 18 Sep 2026 13:29:59 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7C3D241875; Fri, 18 Sep 2026 17:29:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 595261F000FF; Fri, 18 Sep 2026 17:29:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752597; bh=vXQYAj1GDHVUV/kpueHVjpCwP39k1qM4lW2PSzvXObk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hJlp1zclrRFoDLkYwL0hOhx3aD06E6C6j9fHQm1PrgVNSpCX5qlDJVJ/Op97wIKKV z4y7F3g1rJj7zS8/v2ksfORAamDpV0C8Q/k/kTo5Zulsp+TmlgGtaaunPFq/hh2HoI TCSloL/k6eSKX8Jmvu+3mALivHCwGLTKoYGEn/x9doZUMTdTvZBHoCUwP0FMLuw5iF 5ramu0cEYtZNGMjxCj+V3urrnO0NX3CurLWYGtj3gX5Kiv86kGSYQ3SZTX+t1Ol0kq 6sfUAsPyFr7UGHhxgwfj/ID9tcwsnQqzGOhsSMvP28+BUoekSWW0yMECTpH5oeSlqs et5M7vACfvnsA== 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 v5 08/15] block: reject zone appends that are not a multiple of the sector size Date: Fri, 18 Sep 2026 19:29:16 +0200 Message-ID: <20260918172925.2640888-9-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752790843158500 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 da61e641ac..b9d0b3fd7b 100644 --- a/block/io.c +++ b/block/io.c @@ -3355,6 +3355,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 19:59:36 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=1789752670; cv=none; d=zohomail.com; s=zohoarc; b=iFmeCBBqqnXH3M9tKzo1xX9evJPgPkRehZf30y+F1pfY5imBa5KtsC84Y3agq9eTu1hgv9pjwpU/eebeN/K8S7cnA7STWENtWAvOZCofDLHqiYOZXfHzYqpEo5XFj8QMPxmFP3rWRNkO+L40SrH8P9pIob0FOAbAJ9WH8Vs9gxw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752670; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=QXQW7Tj/vJ/h2pt+4J+vyvcuNjENXHEnBN7dKAAkOdE=; b=jX2JiZW4fFVqndP0EFasN7pD2CbwlhfxQXYuUVwd4ekkF/57QWJLAwpYmHm7B/4f5jntXyoKYgqaIQAKB7760GheleLl/R8ZYImaE5FUiy5g6im3Q32Rd+xBbPP9mOWE0hvVqwTY01YCwH88IvdHz8yS8tzp0POvyYtUw/AcZlc= 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 1789752670710356.1228227420879; Fri, 18 Sep 2026 10:31:10 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cQQ-0005Bs-Qe; Fri, 18 Sep 2026 13:31:06 -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 1x7cPU-0004d8-1M; Fri, 18 Sep 2026 13:30:09 -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 1x7cPS-0000Ip-GQ; Fri, 18 Sep 2026 13:30:03 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 142324049D; Fri, 18 Sep 2026 17:30:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2F831F000FF; Fri, 18 Sep 2026 17:29:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752600; bh=QXQW7Tj/vJ/h2pt+4J+vyvcuNjENXHEnBN7dKAAkOdE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=AaPm4vpCvgaOF0EE3WslIAwuzTOB/zjWbUaZ3rQk1G+wZaamtEjKqpaQwn/DR2Jaf j6iLg7ZuAuGg8OCMmELgJVNVnWFm6yAnsgfeuCQA5OD+sLnw4IlacUZ5gSgFGUjSma /kgqOaSYkPEa92pw8cW4mRpygfJB3cKqv6CecV0J/uAzV4glWB5P35vVKKD+MFs/TN Tyz7uee+UEv/fs8yhsOECkNBqpxpAcFu8A0KVuUqw6IJGGT5euoCk3t5GvFUPxQZPy but8+EFtWqxThZs0wF/DMPsfqjLG6EhKU2M5BBfxjNQnHxkvS5+kYdCv+oBWI07QwP L4JquWnjftFUw== 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 v5 09/15] block: reject a zone append that is larger than a zone Date: Fri, 18 Sep 2026 19:29:17 +0200 Message-ID: <20260918172925.2640888-10-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752672040158500 Content-Type: text/plain; charset="utf-8" A zone append cannot cross a zone boundary, so a request larger than a zone can never be carried out. Nothing rejects one. The block layer does not look at the length at all, and raw_co_zone_append() writes qiov->size bytes at the write pointer once it has validated the offset, so the write runs past the end of the zone: on a disk with 8 MiB zones, an append of 8 MiB plus one block fills the zone and advances the write pointer of the zone after it. virtio-blk does compare the length, but against BlockLimits.max_append_sectors, which is how much the backend takes in one command and not how large a zone is. For a Linux block device that value is never larger than a zone, so virtio-blk is protected by what the backend happens to report rather than by the check it makes. Check the length in bdrv_co_zone_append(), next to the check that an append is a multiple of the sector size. Both are conditions of the operation rather than of a medium, so the block layer is where they hold for every caller and where no driver has to repeat them. The exact bound is tighter: a request also has to fit in the part of the zone that is still writable, which depends on the write pointer and so stays with the drivers. Signed-off-by: Niklas Cassel --- block/io.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/block/io.c b/block/io.c index b9d0b3fd7b..d7c403bc08 100644 --- a/block/io.c +++ b/block/io.c @@ -3365,6 +3365,18 @@ int coroutine_fn bdrv_co_zone_append(BlockDriverStat= e *bs, int64_t *offset, return -EINVAL; } =20 + /* + * An append cannot cross a zone boundary, so one that is larger than a + * zone can never be carried out, wherever the write pointer of the zo= ne + * is. The exact bound is the part of the zone that is still writable, + * which only a driver can check, as only it holds the write pointer. + * zone_size is zero when the device is not zoned, which is reported as + * unsupported below. + */ + if (bs->bl.zone_size && qiov->size > bs->bl.zone_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 19:59:36 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=1789752711; cv=none; d=zohomail.com; s=zohoarc; b=lU0pryhrxEIme8gYZLbgd78KMjqnvdTuoVaxxiwgnnoRlpSaY3lACxQovmPXr2u0Z0pCqx3go3GUGSCFiwia16uBCEA4VviuvdKWaaIyUEtjYR51BI8cqHxNAqwNHrtHCU3ItDAONSfQhGrq64i+gs/75Fcqe3+YSc3wQGhTxdA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752711; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=ds0Q2Se8M1KwbjEypJ2cbUozvN0mlOq1Y9vIemv3l5k=; b=PS3oY4oXNFBbCugoP+YXUrR3EFm60lvCAfnyboahx9Ov3RHJ9Tq+NgB7eJUe0Y3Fxs7XAXbtEM6IdoZgYOtKBsxv/JtGOzL5L0ovuUSs0RePzXmdXhYAuzb9il4t/VoNyuQi9ci5SC/KisHe94t4wW1d0B+HoV4Xwj2p5mMfZ7c= 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 17897527111154.690240268298567; Fri, 18 Sep 2026 10:31:51 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cQe-0005m0-T5; Fri, 18 Sep 2026 13:31: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 1x7cPW-0004fl-LF; Fri, 18 Sep 2026 13:30:09 -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 1x7cPU-0000JH-V2; Fri, 18 Sep 2026 13:30:06 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id AA64A60A55; Fri, 18 Sep 2026 17:30:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79A431F000FF; Fri, 18 Sep 2026 17:30:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752602; bh=ds0Q2Se8M1KwbjEypJ2cbUozvN0mlOq1Y9vIemv3l5k=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=FuBW3TuvyBdddPv+ZIthUR+9+CwXfcdw0DrouUyxYRSMiCEmgBXu/jKaSpZjDx04U caC9dZM81w+KIG3w4rsCyLl309OEtvsHv1KXfq4g7Ik/sMPyYFEIaPBI5fpwLHSk2N mTAHHnbFPxhwqKLg66ZO/sRIj31kltEQNoBIWc66Ff1yYyo/Uh7UDRFjKBfj6t/5Sz DvgmjTdsirSQzX4TMHkX9ni+W0+Vnir5/h91J9AzGvr5iXhuISEFrz8uftHt/fsKYe ZTQYGj9DT+k1AMAygVRIv3oE6TRZAD4+NdNQA98vI/avgCCrqLYsCRCS6mulRcg+Zy f+ZN2Yb8XszZw== 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 v5 10/15] file-posix: remove the zone append write granularity check Date: Fri, 18 Sep 2026 19:29:18 +0200 Message-ID: <20260918172925.2640888-11-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752712262158500 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 granularity that holds for every backend is the sector granularity, which is now checked once in bdrv_co_zone_append(). The coarser granularity that a guest has to observe depends on the logical block size that the device was configured with, so only a frontend can know it, and a frontend both reports it to its guest and validates requests against it. Drop the check. BlockLimits.write_granularity is then set in one place, by this driver from the zone_write_granularity queue attribute, and read in one place, where a device whose granularity the configured block sizes cannot express is refused. 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 19:59:36 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=1789752655; cv=none; d=zohomail.com; s=zohoarc; b=k5ufDOdJdRo4d122rFFt5u1f33P2avhNLBp/UiArtFZEKi81qaNWXoBoxTx6bL24BNO5I2WxKvl7IXJ8hRF0o7JRYtO3rJGoDQ3lp9zzXpkJhYFLEKvd1eRGtNvpNTmMel7+eBTNJJTukBR1IAFJjz6FNNGUIzQFlcQubDH0DXs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752655; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=x6bE+olBOh1kMqLDv9SDGWtLLE/Wqq+0hgO1K5YKxWM=; b=MhF6ewced1KIjTjIVcGvtpk+0mm6ceF8dlvKwlEe5uarlbi0ybnx8+SJbDXbXygeNwT/pqFmq3SdWoEc0Shrgaw317XuY6qVoIlkQKx1j3k6oKO649YxuAK5lpC56dSL1CknnUDISRh00aHm5HEWid546d3Apx6Jvg3FJ5ghx6M= 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 1789752655511622.5054015772615; Fri, 18 Sep 2026 10:30:55 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cPz-00050i-1B; Fri, 18 Sep 2026 13:30:41 -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 1x7cPY-0004hW-PE; Fri, 18 Sep 2026 13:30:09 -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 1x7cPW-0000Ld-Em; Fri, 18 Sep 2026 13:30:08 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 1F8074049D; Fri, 18 Sep 2026 17:30:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E929B1F000FF; Fri, 18 Sep 2026 17:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752605; bh=x6bE+olBOh1kMqLDv9SDGWtLLE/Wqq+0hgO1K5YKxWM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=C6qZhuqVkpR0HNPde4bt9HkJsUE5bWTtjug0xuGd3h6keD9C3mvwqL7RaLo632+/0 iDN3DOg1iuoJRrLU/fdb2sENfrVAd8VRCPszy6280FN/uaTdyFulQlxWFrd8+Or8Gw xeuk5kO9L+D+SUQpa837/jXs7xxrv3Wlnq7wNpE5flfyLC4Z2GnqPtADDWuTILvXSr GMV5xanaZP8lgquTKlTAvGqlHXJt5TA0YEyGW4B6l2ZjU/SZhFOPWEv0oorkL7Sgag 2pj8alIcMMLYDE8SHYvMxOj4fh2x1anLAmZ2rIfF/fqLIo8OP810tsI0gb/uzldX10 0rfMk7yb/M0VA== 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 v5 11/15] virtio-blk: add a max-append-sectors property Date: Fri, 18 Sep 2026 19:29:19 +0200 Message-ID: <20260918172925.2640888-12-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752656031158500 Content-Type: text/plain; charset="utf-8" The maximum zone append size that the device reports to its driver was taken from BlockLimits.max_append_sectors, a limit of the host disk that the backend happens to sit on. A guest reads it out of the configuration space, so it becomes part of what the guest has been told about its device, and migrating that guest to a host whose disks report something smaller leaves it appending more than the device accepts. Make it a property, as max-discard-sectors and max-write-zeroes-sectors already are, so that the value a guest is given is part of the device model and does not change under it. Nothing from BlockLimits reaches the configuration space any more. Zero is a valid value here, unlike for those two. There is no feature bit for zone append, and a maximum of zero is how the specification has a device say that it does not support the operation (virtio 1.4, 5.2.5.2). It is also what a ZBC or ZAC disk is: such a disk has no zone append command at all, and Linux emulates one in its block layer. What is reported is capped by the size of a zone. The specification asks for the largest append that can be carried out, and one larger than a zone never can be, so the default would otherwise advertise a size that the block layer refuses. The cap tells a guest nothing about the host that zone_sectors has not already told it. Signed-off-by: Niklas Cassel --- hw/block/virtio-blk.c | 67 ++++++++++++++++++++++++++++++---- include/hw/virtio/virtio-blk.h | 1 + 2 files changed, 61 insertions(+), 7 deletions(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index 74bd08b0ec..536d71a91a 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -521,6 +521,24 @@ typedef struct ZoneCmdData { }; } ZoneCmdData; =20 +/* + * The maximum zone append size that the device reports to its driver, in = 512 + * byte sectors. + * + * An append cannot cross a zone boundary, so the configured maximum is ca= pped + * by the size of a zone: the specification asks for the largest append th= at + * can be carried out, and a larger one never can be. The zone size is alr= eady + * reported to the driver as zone_sectors, so this tells it nothing new ab= out + * the host. + */ +static uint32_t virtio_blk_max_append_sectors(VirtIOBlock *s) +{ + BlockDriverState *bs =3D blk_bs(s->blk); + + return MIN(s->conf.max_append_sectors, + bs->bl.zone_size >> BDRV_SECTOR_BITS); +} + /* * check zoned_request: error checking before issuing requests. If all che= cks * passed, return true. @@ -556,12 +574,13 @@ 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 (!s->conf.max_append_sectors) { + *status =3D VIRTIO_BLK_S_UNSUPP; + return false; + } + + if ((len >> BDRV_SECTOR_BITS) > virtio_blk_max_append_sectors(s)) { + *status =3D VIRTIO_BLK_S_ZONE_INVALID_CMD; return false; } } @@ -1315,7 +1334,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; } @@ -1852,6 +1871,34 @@ static void virtio_blk_device_realize(DeviceState *d= ev, Error **errp) } } =20 + if (virtio_has_feature(s->host_features, VIRTIO_BLK_F_ZONED)) { + uint32_t wg =3D blkconf_zone_write_granularity(&conf->conf); + + /* + * Checked before the granularity below, so that a driver can shif= t the + * value that it reads into a byte count without overflowing. + */ + if (conf->max_append_sectors > BDRV_REQUEST_MAX_SECTORS) { + error_setg(errp, "invalid max-append-sectors property (%" PRIu= 32 + "), must not exceed %d", conf->max_append_sectors, + (int)BDRV_REQUEST_MAX_SECTORS); + return; + } + + /* + * Zero is allowed, and says that zone append is not supported, wh= ich + * is what a ZBC or ZAC disk is. Anything else has to be able to + * express a single write. + */ + if (conf->max_append_sectors && + (conf->max_append_sectors << BDRV_SECTOR_BITS) < wg) { + error_setg(errp, "invalid max-append-sectors property (%" PRIu= 32 + "), must be zero or at least the zone write granula= rity " + "(%" PRIu32 " bytes)", conf->max_append_sectors, wg= ); + return; + } + } + if (virtio_has_feature(s->host_features, VIRTIO_BLK_F_DISCARD) && (!conf->max_discard_sectors || conf->max_discard_sectors > BDRV_REQUEST_MAX_SECTORS)) { @@ -1986,6 +2033,12 @@ static const Property virtio_blk_properties[] =3D { conf.max_discard_sectors, BDRV_REQUEST_MAX_SECTORS), DEFINE_PROP_UINT32("max-write-zeroes-sectors", VirtIOBlock, conf.max_write_zeroes_sectors, BDRV_REQUEST_MAX_SEC= TORS), + /* + * Zero is valid, and says that the device does not support zone appen= d, + * as a ZBC or ZAC disk does not. + */ + DEFINE_PROP_UINT32("max-append-sectors", VirtIOBlock, + conf.max_append_sectors, BDRV_REQUEST_MAX_SECTORS), DEFINE_PROP_BOOL("x-enable-wce-if-config-wce", VirtIOBlock, conf.x_enable_wce_if_config_wce, true), }; diff --git a/include/hw/virtio/virtio-blk.h b/include/hw/virtio/virtio-blk.h index 3d8dee7ec1..0070ca6ba9 100644 --- a/include/hw/virtio/virtio-blk.h +++ b/include/hw/virtio/virtio-blk.h @@ -47,6 +47,7 @@ struct VirtIOBlkConf bool report_discard_granularity; uint32_t max_discard_sectors; uint32_t max_write_zeroes_sectors; + uint32_t max_append_sectors; bool x_enable_wce_if_config_wce; }; =20 --=20 2.55.0 From nobody Sat Sep 26 19:59:36 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=1789752780; cv=none; d=zohomail.com; s=zohoarc; b=IB+qb2iXJePO3qqIIZKpjDSknh2N3JQSVIvLGD6MqJpUfEbTtP1JEWTr4e+mVhS2SAvE0yWpblbr2gmm2cU6vDZDtShvDk+crd+0M9g0j18mTb70K6RWAowN889iGipdiKO+/W2uDGT/CAV8tQSqx5T3IXfoH+oG3Tyu+S7yjQc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752780; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=aJ4D99PRE9FsrB0XYN1JFXE/oB3XRrxb2xhanlbrQFI=; b=CNH9UTlRhqgBAGQ+A8QZ/P2W7CWfEIfj5vbjKIinhNaiwGOF/9wEgmXJidJbkqMOwdk/BhPni0V4E0046Tn+X7tIeRyNusuJoRtHMwNdwfVYHGjLFo8rTXldl5uup8PD01LlYivprYq1ee0KJmlO7GSjAxy8ApI4twNacpaOQ3Q= 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 1789752780240657.8601398002314; Fri, 18 Sep 2026 10:33:00 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cS1-0007NO-LI; Fri, 18 Sep 2026 13:32: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 1x7cPa-0004lc-UJ; Fri, 18 Sep 2026 13:30:12 -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 1x7cPY-0000Vf-RY; Fri, 18 Sep 2026 13:30:10 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 7EAC840F24; Fri, 18 Sep 2026 17:30:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 897491F000FF; Fri, 18 Sep 2026 17:30:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752607; bh=aJ4D99PRE9FsrB0XYN1JFXE/oB3XRrxb2xhanlbrQFI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ATyu0SAeIXzY1Walxg2RQA4UlYrAJH6qh3ESu+gXaYbvCCFx1BB0i4LdaHWZkZbbk 2ePGKOVGkUMCKs9P6+ZHtqKY38vBTr1mUV2h0LkujIqQ11455dcCUq8p4+Dp68lO7W FWfbPJGEIfilsKKTXQzAL4Mzek2i0WSboFZQFT3UlFjtmiKsElZHUG9Zn4BNmpwGqr 5Lw0+YrgaIkplBRySMhLk+2mFRzKXnNOxGoaChIJ7T9A1+SkS4ByTpvXN8OnhzWM0r 1VzDJ+SKaZBSoXaAcy3x7R3p1mmqaQdlNNQcyc8rM3bgkrG/bwkdWJ02xdrafDWg83 8bn+dCZ0pZ6SQ== 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 v5 12/15] block: remove BlockLimits.max_append_sectors Date: Fri, 18 Sep 2026 19:29:20 +0200 Message-ID: <20260918172925.2640888-13-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752780649158500 Content-Type: text/plain; charset="utf-8" The field described the largest zone append that a backend accepts. It had one writer and one reader, and neither is left. file-posix filled it from the zone_append_max_bytes queue attribute, which bounds REQ_OP_ZONE_APPEND, an operation it never issues: Linux has no userspace interface for one, so raw_co_zone_append() substitutes the write pointer of the zone for the offset and the request reaches the host as a plain pwritev(). The transfer limit does not apply either, no more than it does to an ordinary write. This driver reports max_hw_transfer but never sets BlockLimits.max_transfer, which is what bdrv_aligned_pwritev() splits by, so a request of any size goes to the host kernel whole and is split there: 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. That is safe for a sequential zone, as Linux issues the fragments of a split write in order, with zone write plugging since 6.10 and zone write locking before that. virtio-blk was the reader, and now takes what it reports to a guest from a property instead. Remove the field and the assignment that filled it. Keeping it would be worse than not having it: a driver that set it, believing something enforced it, would be silently ignored. Signed-off-by: Niklas Cassel --- block/file-posix.c | 5 ----- include/block/block_int-common.h | 3 --- 2 files changed, 8 deletions(-) diff --git a/block/file-posix.c b/block/file-posix.c index c1ac49d23d..1a4ca9d942 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -1488,11 +1488,6 @@ static void raw_refresh_zoned_limits(BlockDriverStat= e *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; - } - ret =3D get_sysfs_long_val(st, "zone_write_granularity"); if (ret >=3D 0) { bs->bl.write_granularity =3D ret; diff --git a/include/block/block_int-common.h b/include/block/block_int-com= mon.h index 7abd2b12bb..cfc7b0f427 100644 --- a/include/block/block_int-common.h +++ b/include/block/block_int-common.h @@ -913,9 +913,6 @@ typedef struct BlockLimits { /* total number of zones */ uint32_t nr_zones; =20 - /* maximum sectors of a zone append write operation */ - uint32_t max_append_sectors; - /* maximum number of open zones */ uint32_t max_open_zones; =20 --=20 2.55.0 From nobody Sat Sep 26 19:59:36 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=1789752730; cv=none; d=zohomail.com; s=zohoarc; b=h3m2LRYOXCgodX2Bax50/EKQbzaZUMDqOdjzlwbrhZmvi09b+8AMafZ2pfvhd67jFbOlGyak/L1lYH8ujjuEfjKdsSW5J+P17JZey6Kdniz1KNisyJQpsrZ9ueqA3EjeV/60EAKTYOB9VjXewC9nnoI/h5mqup3rvshrv2UXTVU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752730; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=ySO9zwKiPq1/FpeOZDH8TBjob3RLyJpfcKQBmejVpw0=; b=PrYLtg1QdwJr9uLGmALWN3BXrEBsyGQsNa0Y6lIt9v2VHgUoMSuFCYywwul9mFwSO8GoW3oLDvtrlWLZRijsGZsQ6HCCBeCny1L86ykH5dYQSQxpMal6vO9axHPkXJ/upc4o47Gg42uTvzsedBP5ywbyqZyzq8gcXLdYVyn5mK4= 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 1789752730496426.6733064968894; Fri, 18 Sep 2026 10:32:10 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cQx-00062z-Gc; Fri, 18 Sep 2026 13:31: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 1x7cPc-0004pr-U1; Fri, 18 Sep 2026 13:30:17 -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 1x7cPb-0000WA-Cx; Fri, 18 Sep 2026 13:30:12 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 135136053D; Fri, 18 Sep 2026 17:30:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E540C1F000FF; Fri, 18 Sep 2026 17:30:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752609; bh=ySO9zwKiPq1/FpeOZDH8TBjob3RLyJpfcKQBmejVpw0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=gLEtYy9aYLhsjBbnpxBF+gUoVDoHpaRbfR0F0bYLuVnlz0cHMPwIzuTI0je9//1IR PkOq6ty4SQ382sdZKQekPmALUm+TSMHtn/oBMF+D+rgonVmPsxYEq7mVTS1hR70Iwb 9wvVgPRN1iOZ4dtRN7R1xxx7R4gfgUJyEJlXzubZexBARZ5y0DVu8y/moeGVLXjdGq 56PqqHts1oH0ReaWDUUWhmzjhwNBZeAoyhuuhyy4XkY4ZnrvYv2Ze0IL09mVPs0gat Yo4yBSfCd9G1KXN1JxtE2y7ZVNGI/0eoeASAPoDZmKVMr7uHd2fPA7DKjTNsUvwlzV h9JGGHH+o5EPg== 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 v5 13/15] file-posix: reject a zone append past the device capacity Date: Fri, 18 Sep 2026 19:29:21 +0200 Message-ID: <20260918172925.2640888-14-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752732382158500 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 1a4ca9d942..e1e6a03b25 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -3587,8 +3587,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 19:59:36 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=1789752706; cv=none; d=zohomail.com; s=zohoarc; b=cO/5cqF+sj1ypS1ijmE525Sx5g3CJGCB+l6FokSoNBVPUoBfjlI7PE7mg2h/3xGlxvSfonK0j6UBvIq6vC6SKB1byKylMBljFJTgxRVK5FpqKA1kWmgWAypa4lhubMSOP+OIpkbJSHrSCrIDlGyYL5m3zxfKLUa9pdwlMk7bltA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752706; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=k32dDdeu7VNv3z/8LJ7JkF9xnbBSxrnGFp4OnDnk7qI=; b=C0yEYpPWaEt7feoTnzBojpSJdL/7TU/+ecd+wKCk98sHE6wbBmhq5MKfi1SvUfIE15ChzePs7gQ5+VRnDc+qBXFSdjI/QcR4hT3sLhL6teS5fEqrm/5LamIHAvxVNhiYCL8E8kKA+4aDW7EhcHsH5j2zX62S63p6YCb0fmKnWLM= 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 1789752706111271.1096901463062; Fri, 18 Sep 2026 10:31:46 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cQ6-000510-Mv; Fri, 18 Sep 2026 13:30: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 1x7cPf-0004qI-Fn; Fri, 18 Sep 2026 13:30: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 1x7cPd-0000Wb-Mi; Fri, 18 Sep 2026 13:30:15 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 79AD64049D; Fri, 18 Sep 2026 17:30:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54BB01F000FF; Fri, 18 Sep 2026 17:30:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752612; bh=k32dDdeu7VNv3z/8LJ7JkF9xnbBSxrnGFp4OnDnk7qI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UF5tORiICyVxWzVC6KNdvCFo5uavr4vBnZnyvtgO98Sa7j8DOs/vsl52en5IbLEqE v7wf3KAcCnrkq1GvwlMknmM3I/D+yY33pvhNgwe5/KfFvd+Njuu6WKBi9OcE76iQ7J RW1lBpPXxeLPLOqeqLxzNwce1UjfWdA0KxnmEscoSYU0VBTe4OK6gZfWRFnhS/3GDQ Zz6Q1CaVjmdLQaXjpliQ9xFxpamD5I8FwrOSzU/eIH4bVRWQdn3JgR97kVuq5tWmrh Vu1xff7gQSaBOgT/TZp75vvsyO8csemHWL3swK9jJh0WBO4XUwMVMgdk4scYmZpzzO 3gq/xWUoWHYlQ== 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 v5 14/15] file-posix: reject a zone append to a full or conventional zone Date: Fri, 18 Sep 2026 19:29:22 +0200 Message-ID: <20260918172925.2640888-15-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752708386158502 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") Reviewed-by: Damien Le Moal Signed-off-by: Niklas Cassel --- block/file-posix.c | 23 ++++++++++++++++++++++- block/io.c | 9 +++++++++ include/block/block-io.h | 6 ++++++ 3 files changed, 37 insertions(+), 1 deletion(-) diff --git a/block/file-posix.c b/block/file-posix.c index e1e6a03b25..cd3c9f0fd0 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -2555,7 +2555,28 @@ 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); + uint32_t index =3D bdrv_zone_index(bs, offset); + + /* + * The write pointer of the addressed zone becomes the offset = of + * the write, so it has to name a position inside that zone. A + * conventional zone has no write pointer, and the pointer of a + * full zone is reported at the end of the zone. Either would = send + * the data to a zone that was never addressed. + */ + if (bdrv_zone_is_conv(bs, index)) { + 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 bs->wps->wp[index]; } } diff --git a/block/io.c b/block/io.c index d7c403bc08..a4fb56f799 100644 --- a/block/io.c +++ b/block/io.c @@ -3402,6 +3402,15 @@ bool bdrv_zone_is_conv(BlockDriverState *bs, uint32_= t index) return BDRV_ZT_IS_CONV(bs->wps->wp[index]); } =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 e469df7061..f671476f08 100644 --- a/include/block/block-io.h +++ b/include/block/block-io.h @@ -134,6 +134,12 @@ uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_= t offset); * bdrv_zone_is_full() this does not need the write pointer lock. */ bool bdrv_zone_is_conv(BlockDriverState *bs, uint32_t index); +/* + * 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 From nobody Sat Sep 26 19:59:36 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=1789752756; cv=none; d=zohomail.com; s=zohoarc; b=aJ2uiBe7/+FBDZhcnZoJstxrzXF/lFOTa3aHRabwN8WMDYJqDdGQpfi8wPyx0iGA956Sr8QY77hzPuJ9jFoqQaAKCrZKn0w5xCF65mybImqxKCUyDj1ZjSZATWjsFOVstcKoYJCG4IxjofCGI98IzBf3ezJRQYRyEZmc+WQIyZ0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1789752756; 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:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=wkePXI2ZAhs57urNC3Xrzyj8N64ULkLTlQbeBh3xUWk=; b=A3Z8Y5qNnhjOLPmNPRXmiJcbDbPyW0ClRbyQVWh6jvWIBK9FH4VT3cJ7+rE3+ltJwGYUpr+Yj2KC8JqXSP+bxgCVMiGSB5RRuAbAxBwwkAfCZL+YIWf6uYGg4Qd4IddF/kmAY2wkcgqN18dZ1eHphHLQI8oTGoH5yVc+gJLob3M= 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 1789752756953968.2144964633054; Fri, 18 Sep 2026 10:32:36 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1x7cR0-00069y-KI; Fri, 18 Sep 2026 13:31: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 1x7cPj-0004qg-5L; Fri, 18 Sep 2026 13:30: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 1x7cPg-0000Ww-5T; Fri, 18 Sep 2026 13:30:17 -0400 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 3CABD6053D; Fri, 18 Sep 2026 17:30:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E00B31F000FF; Fri, 18 Sep 2026 17:30:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789752614; bh=wkePXI2ZAhs57urNC3Xrzyj8N64ULkLTlQbeBh3xUWk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=CVzQrGourI1q4QpFbSes7/dYfTMPKYo7gTMSfl3V+pucUJZZMVnfKfSSybkK5fzJw t1rSKRQ3xrpzwtwo6cMc5GsNyGAnevTu3UJ4BwT5f+5yoPvJJ9EShCjiPZVZfOR40I 4Xr2ymvLUY53KNWxxsIYPUKcPBG0tNes/RokfJGXh08XdApA6Tv+XZJFnVJFG2S0bP gy2ODR1/9fEL6rv2L45/yBKnmBQblIkUa2mdnl9QAHqYNNtigBxE8Uo+ds3bGFMDA+ BT9OzygS1vkYZRqna5/I/LKigOd3KRX7VnRvjRIb2gqwwiihSVHn1n0zI0Ib8QYqpN E2y8llc2ePUJA== 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 v5 15/15] block: do not use CoroutineIOCompletion to hold a return value Date: Fri, 18 Sep 2026 19:29:23 +0200 Message-ID: <20260918172925.2640888-16-cassel@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260918172925.2640888-1-cassel@kernel.org> References: <20260918172925.2640888-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: 1789752758609158500 Content-Type: text/plain; charset="utf-8" bdrv_co_zone_report(), bdrv_co_zone_mgmt() and bdrv_co_zone_append() each declare a CoroutineIOCompletion in order to use its ret field, and never touch the coroutine field that the rest of the structure exists for. That structure is for a request which completes through bdrv_co_io_em_complete(), where the callback has to store the result somewhere and wake the coroutine that is waiting for it. These three call into the driver directly and are already running in the coroutine that wants the result, so there is nothing to wake and nowhere else for the value to live. Use a plain int. bdrv_co_zone_append() already has one. Suggested-by: Stefan Hajnoczi Signed-off-by: Niklas Cassel --- block/io.c | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/block/io.c b/block/io.c index a4fb56f799..c62c3764d3 100644 --- a/block/io.c +++ b/block/io.c @@ -3303,40 +3303,36 @@ int coroutine_fn bdrv_co_zone_report(BlockDriverSta= te *bs, int64_t offset, BlockZoneDescriptor *zones) { BlockDriver *drv =3D bs->drv; - CoroutineIOCompletion co =3D { - .coroutine =3D qemu_coroutine_self(), - }; + int ret; IO_CODE(); =20 bdrv_inc_in_flight(bs); if (!drv || !drv->bdrv_co_zone_report || bs->bl.zoned =3D=3D BLK_Z_NON= E) { - co.ret =3D -ENOTSUP; + ret =3D -ENOTSUP; goto out; } - co.ret =3D drv->bdrv_co_zone_report(bs, offset, nr_zones, zones); + ret =3D drv->bdrv_co_zone_report(bs, offset, nr_zones, zones); out: bdrv_dec_in_flight(bs); - return co.ret; + return ret; } =20 int coroutine_fn bdrv_co_zone_mgmt(BlockDriverState *bs, BlockZoneOp op, int64_t offset, int64_t len) { BlockDriver *drv =3D bs->drv; - CoroutineIOCompletion co =3D { - .coroutine =3D qemu_coroutine_self(), - }; + int ret; IO_CODE(); =20 bdrv_inc_in_flight(bs); if (!drv || !drv->bdrv_co_zone_mgmt || bs->bl.zoned =3D=3D BLK_Z_NONE)= { - co.ret =3D -ENOTSUP; + ret =3D -ENOTSUP; goto out; } - co.ret =3D drv->bdrv_co_zone_mgmt(bs, op, offset, len); + ret =3D drv->bdrv_co_zone_mgmt(bs, op, offset, len); out: bdrv_dec_in_flight(bs); - return co.ret; + return ret; } =20 int coroutine_fn bdrv_co_zone_append(BlockDriverState *bs, int64_t *offset, @@ -3345,9 +3341,6 @@ int coroutine_fn bdrv_co_zone_append(BlockDriverState= *bs, int64_t *offset, { int ret; BlockDriver *drv =3D bs->drv; - CoroutineIOCompletion co =3D { - .coroutine =3D qemu_coroutine_self(), - }; IO_CODE(); =20 ret =3D bdrv_check_qiov_request(*offset, qiov->size, qiov, 0, NULL); @@ -3379,13 +3372,13 @@ int coroutine_fn bdrv_co_zone_append(BlockDriverSta= te *bs, int64_t *offset, =20 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; + ret =3D -ENOTSUP; goto out; } - co.ret =3D drv->bdrv_co_zone_append(bs, offset, qiov, flags); + ret =3D drv->bdrv_co_zone_append(bs, offset, qiov, flags); out: bdrv_dec_in_flight(bs); - return co.ret; + return ret; } =20 uint32_t bdrv_zone_index(BlockDriverState *bs, uint64_t offset) --=20 2.55.0