On Wed, Sep 09, 2026 at 02:27:55PM -0400, Stefan Hajnoczi wrote:
> On Mon, Sep 07, 2026 at 01:07:39PM +0200, Niklas Cassel wrote:
> > @@ -1274,7 +1274,8 @@ static void virtio_blk_update_config(VirtIODevice
> > *vdev, 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 {
>
> The device emulation code cannot expose the limit value from the host
> device because that would break live migration: a guest device must
> remain unchanged across migration and the VIRTIO Configuration Space
> cannot change field values if the source and destination hosts have
> different disks. The guest driver does not expect these values to
> change once the device has been probed.
>
> For example, it would be possible to migrate from a host with a write
> granularity of 64 KB to a host with a write granularity of 4 KB. The
> guest must still see a 64 KB write granularity the entire time (even
> after migration).
>
> For this reason, limits on guest devices must be configured explicitly
> rather than automatically populated from the host device limits.
Sure, this can easily be implemented as:
MAX(conf->logical_block_size, conf->physical_block_size)
which is a pure function of the device configuration.
>
> Could you implement an error when the guest limit has not been
> configured appropriately for the given BlockBackend instead?
Will do.
Kind regards,
Niklas
