On Mon, Sep 21, 2026 at 04:28:13PM +0200, Niklas Cassel wrote: > The maximum zone append size that the device reports to its driver was > taken from BlockLimits.max_append_sectors, a limit of the host disk that > the backend happens to sit on. A guest reads it out of the configuration > space, so it becomes part of what the guest has been told about its > device, and migrating that guest to a host whose disks report something > smaller leaves it appending more than the device accepts. > > Make it a property, as max-discard-sectors and max-write-zeroes-sectors > already are, so that the value a guest is given is part of the device > model and does not change under it. Nothing from BlockLimits reaches the > configuration space any more. > > Zero is a valid value here, unlike for those two. There is no feature bit > for zone append, and a maximum of zero is how the specification has a > device say that it does not support the operation (virtio 1.4, 5.2.5.2). > It is also what a ZBC or ZAC disk is: such a disk has no zone append > command at all, and Linux emulates one in its block layer. > > What is reported is capped by the size of a zone. The specification asks > for the largest append that can be carried out, and one larger than a > zone never can be, so the default would otherwise advertise a size that > the block layer refuses. The cap tells a guest nothing about the host > that zone_sectors has not already told it. > > Signed-off-by: Niklas Cassel <[email protected]> > --- > hw/block/virtio-blk.c | 67 ++++++++++++++++++++++++++++++---- > include/hw/virtio/virtio-blk.h | 1 + > 2 files changed, 61 insertions(+), 7 deletions(-)
Before virtio-blk reported bs->bl.max_append_sectors to the guest. Now the default value is MAX_INT >> BDRV_SECTOR_BITS. This is a guest-visible change (e.g. when upgrading QEMU versions) and we normally avoid that. In this case it's a bug that the host value was exposed in the first place and it is unlikely that anyone is using zoned storage emulation in a use case that involves migration. Therefore I think we can allow this change. Reviewed-by: Stefan Hajnoczi <[email protected]>
signature.asc
Description: PGP signature
