All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Niklas Cassel <cassel@kernel.org>
Cc: Kevin Wolf <kwolf@redhat.com>, John Snow <jsnow@redhat.com>,
	"Denis V. Lunev" <den@openvz.org>,
	Hanna Reitz <hreitz@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Sam Li <faithilikerun@gmail.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH v6 07/15] hw/block: reject a zoned device that the block sizes cannot address
Date: Tue, 22 Sep 2026 15:01:23 -0400	[thread overview]
Message-ID: <20260922190123.GC340123@fedora> (raw)
In-Reply-To: <20260921142819.2916043-8-cassel@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On Mon, Sep 21, 2026 at 04:28:09PM +0200, Niklas Cassel wrote:
> 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=512
> leaves a write pointer that logical_block_size=4096 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 <cassel@kernel.org>
> ---
>  hw/block/block.c         | 63 ++++++++++++++++++++++++++++++++++++++++
>  hw/block/virtio-blk.c    |  4 +++
>  include/hw/block/block.h |  1 +
>  3 files changed, 68 insertions(+)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2026-09-22 19:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 14:28 [PATCH v6 00/15] block: fix the zone write granularity and the zone append limit Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 01/15] block: widen BlockLimits.zone_size to uint64_t Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 02/15] virtio-blk: do not merge requests across a zone boundary Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 03/15] block: add a helper for the index of the zone an offset falls in Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 04/15] block: add a helper to check if a zone is conventional Niklas Cassel
2026-09-22 18:55   ` Stefan Hajnoczi
2026-09-21 14:28 ` [PATCH v6 05/15] hw/block: derive the zone write granularity from the block sizes Niklas Cassel
2026-09-22 18:58   ` Stefan Hajnoczi
2026-09-21 14:28 ` [PATCH v6 06/15] virtio-blk: check the write granularity of writes to sequential zones Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 07/15] hw/block: reject a zoned device that the block sizes cannot address Niklas Cassel
2026-09-22 19:01   ` Stefan Hajnoczi [this message]
2026-09-21 14:28 ` [PATCH v6 08/15] block: reject zone appends that are not a multiple of the sector size Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 09/15] block: reject a zone append that is larger than a zone Niklas Cassel
2026-09-22 19:04   ` Stefan Hajnoczi
2026-09-21 14:28 ` [PATCH v6 10/15] file-posix: remove the zone append write granularity check Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 11/15] virtio-blk: add a max-append-sectors property Niklas Cassel
2026-09-22 19:14   ` Stefan Hajnoczi
2026-09-21 14:28 ` [PATCH v6 12/15] block: remove BlockLimits.max_append_sectors Niklas Cassel
2026-09-22 19:16   ` Stefan Hajnoczi
2026-09-21 14:28 ` [PATCH v6 13/15] file-posix: reject a zone append past the device capacity Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 14/15] file-posix: reject a zone append to a full or conventional zone Niklas Cassel
2026-09-21 14:28 ` [PATCH v6 15/15] block: do not use CoroutineIOCompletion to hold a return value Niklas Cassel
2026-10-06 13:15 ` [PATCH v6 00/15] block: fix the zone write granularity and the zone append limit Niklas Cassel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260922190123.GC340123@fedora \
    --to=stefanha@redhat.com \
    --cc=cassel@kernel.org \
    --cc=den@openvz.org \
    --cc=dlemoal@kernel.org \
    --cc=faithilikerun@gmail.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.