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.
Kind regards,
Niklas
