On Tue, Nov 3, 2026 at 10:41 AM Michael S. Tsirkin <[email protected]> wrote: > > 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? >
I meant that QEMU free the shadow virtqueue members on vring stop, but I was wrong about free_head. What QEMU actually free is each descriptor state (and the queue itself), as it could be resized on each reset. free_head member should be set to 0 too. Li RongQing, would you mind sending a patch to the QEMU mailing list with that? Thanks!
