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 as far as I know. Do you have a reproducer or something similar?
