Re: [PATCH v11 3/5] virtio-blk: do not merge writes across a zone boundary

[Sam Li]

On Tue, Jun 9, 2026 at 6:01 PM Stefan Hajnoczi <stefa...@redhat.com> wrote:
>
> On Mon, Jun 08, 2026 at 02:00:03PM +0200, Niklas Cassel wrote:
> > Hello Stefan,
> >
> > On Wed, Jun 03, 2026 at 04:41:50PM -0400, Stefan Hajnoczi wrote:
> > > On Mon, Jun 01, 2026 at 11:44:03PM +0200, Sam Li wrote:
> > > > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> > > > index 9cb9f1fb2b..285db19ac7 100644
> > > > --- a/hw/block/virtio-blk.c
> > > > +++ b/hw/block/virtio-blk.c
> > > > @@ -303,17 +306,34 @@ static void 
> > > > virtio_blk_submit_multireq(VirtIOBlock *s, MultiReqBuffer *mrb)
> > > >      for (i = 0; i < mrb->num_reqs; i++) {
> > > >          VirtIOBlockReq *req = mrb->reqs[i];
> > > >          if (num_reqs > 0) {
> > > > +            zone_cross = false;
> > > > +
> > > > +            /*
> > > > +             * On zoned backends, a single backend write must not span 
> > > > a zone
> > >
> > > This code handles both reads and writes but the comment only mentions
> > > writes. I think reads are allowed to span zones, so should there be a
> > > check that mrb->is_write?
> >
> > From the Virtual I/O Device (VIRTIO) Version 1.4 specification:
> >
> > "If a VIRTIO_BLK_T_ZONE_APPEND request, a VIRTIO_BLK_T_IN request or a
> > VIRTIO_BLK_T_OUT request issued to a SWR zone has the range that has
> > sectors in more than one zone, then the request SHALL be completed with
> > VIRTIO_BLK_S_ZONE_INVALID_CMD value in the field status."
> >
> >
> > Thus, while this is allowed to read past the zone boundary in many zoned
> > specifications, e.g. in both ZAC and ZBC, when the "Read Across Zone
> > Boundaries bit" is set, is seems like it is never allowed to do so in
> > VIRTIO.
>
> Hi Niklas,
> Thanks for pointing this out. So no change is needed here.
>
> I noticed that NVMe has a Read Across Zone Boundaries bit to indicate
> whether or not this is allowed. virtio-blk could add a feature bit to
> offer the same functionality in the future. This would come in handy if
> existing applications depend on reading across zones.

Sounds like a good addition to the persistent metadata for ZNS emulation series?

Sam