Re: [PATCH v4 10/12] virtio-blk: derive the maximum zone append size

[Stefan Hajnoczi <stefanha@redhat.com>]

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

On Wed, Sep 16, 2026 at 11:16:27PM +0200, Niklas Cassel wrote:
> On Wed, Sep 09, 2026 at 02:52:47PM -0400, Stefan Hajnoczi wrote:
> > On Mon, Sep 07, 2026 at 01:07:45PM +0200, Niklas Cassel wrote:
> > > @@ -1313,7 +1330,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 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));
> > 
> > This has the same issue as the write_granularity patch earlier in this
> > patch series, except that max_append_sectors was already exposing the
> > BlockBackends BlockLimits, which we shouldn't do.
> 
> If we can't derive it from any field in bs->blk, then the best thing I can
> think of (that hay precedence) is to add a virtio-blk property:
> 
> DEFINE_PROP_UINT32("max-append-sectors", VirtIOBlock,
>                    conf.max_append_sectors, BDRV_REQUEST_MAX_SECTORS),
> 
> Since it is very similar to the existing virtio-blk properties:
> 
>     DEFINE_PROP_UINT32("max-discard-sectors", VirtIOBlock,                      
>                        conf.max_discard_sectors, BDRV_REQUEST_MAX_SECTORS),     
>     DEFINE_PROP_UINT32("max-write-zeroes-sectors", VirtIOBlock,                 
>                        conf.max_write_zeroes_sectors, BDRV_REQUEST_MAX_SECTORS),
> 
> 
> 
> However, your argument reaches beyond this patch:
> zoned.model, zone_sectors, max_open_zones and max_active_zones are all
> read from bs->bl in virtio_blk_update_config(), and VIRTIO_BLK_F_ZONED
> itself is set from bs->bl.zoned at realize.
> 
> Should I just let them be?
> 
> Seems out of scope of this series, but following your argument, I'm
> wondering if they shouldn't have been virtio-blk properties as well.

I agree it's out of scope. Feel free to leave it.

How I think about block limits and migration:

Explicit properties make sense where live migration is possible across
different values. Migrating across changing zoned.model, zone_sectors,
max_open_zones, max_active_zones is very hard or impossible, so directly
exposing values from the host is fine here.

Looking at max_append_sectors from that perspective, an explicit
property enables migration from a source host with a lower
max_append_sectors to a destination host with a higher
max_append_sectors. So a property would be appropriate, I think.

Stefan

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