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
signature.asc
Description: PGP signature
