On Tue, Nov 03, 2026 at 10:36:26AM +0100, Eugenio Perez Martin wrote: > On Fri, Sep 11, 2026 at 8:05 AM Li,Rongqing <[email protected]> wrote: > > > > > > > > > > The IN_ORDER feature uses additional software state to track the next > > > > available descriptor and in-flight descriptor batches. > > > > > > > > virtqueue_init() resets the common virtqueue state, but free_head and > > > > batch_last.id are initialized only when the virtqueue is created. When > > > > an IN_ORDER virtqueue is reset, these fields can retain state from the > > > > previous queue instance. > > > > > > > > Reset free_head and invalidate batch_last when initializing an > > > > IN_ORDER virtqueue. Keep this in virtqueue_init() so the state is > > > > initialized consistently for both newly created and reset virtqueues. > > > > > > > > Fixes: f6a15d854986 ("virtio_ring: add in order support") > > > > > > I think this is needed for -stable. > > > > > > > Signed-off-by: Li RongQing <[email protected]> > > > > --- > > > > drivers/virtio/virtio_ring.c | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c > > > > b/drivers/virtio/virtio_ring.c index db678f5..d0dc464 100644 > > > > --- a/drivers/virtio/virtio_ring.c > > > > +++ b/drivers/virtio/virtio_ring.c > > > > @@ -559,6 +559,11 @@ static void virtqueue_init(struct vring_virtqueue > > > > *vq, > > > u32 num) > > > > vq->in_use = false; > > > > vq->last_add_time_valid = false; #endif > > > > + > > > > + if (virtqueue_is_in_order(vq)) { > > > > + vq->free_head = 0; > > > > + vq->batch_last.id = UINT_MAX; > > > > + } > > > > > > I would try to reuse or refactor virtqueue_vring_attach_split() to reduce > > > code > > > duplication. > > > > > > Btw have you checked Qemu shadow virtqueue as it might suffer from the > > > same > > > issue. > > > > > > > I checked QEMU's shadow virtqueue implementation. batch_last is > > reinitialized in vhost_svq_start(), > > but free_head is not. Since the SVQ object can be reused across stop/start, > > free_head may retain stale > > state. So a corresponding fix should be needed > > > > void vhost_svq_start(VhostShadowVirtqueue *svq, VirtIODevice *vdev, > > VirtQueue *vq, VhostIOVATree *iova_tree) > > { > > ... > > svq->shadow_avail_idx = 0; > > svq->shadow_used_idx = 0; > > + svq->free_head = 0; > > memset(&svq->batch_last, 0, sizeof(svq->batch_last)); > > svq->last_used = 0; > > svq->last_used_idx = 0; > > > > I'll ack this patch if it is sent to the QEMU mailing list, but the > guest is not able to reset a virtqueue without deallocating it
what would "deallocating" mean here? who's doing the deallocating? > as far > as I know. Do you have a reproducer or something similar?
