[PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

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")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 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;
+	}
 }
 
 
-- 
2.9.4

Re: [PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[Jason Wang]

On Thu, Sep 10, 2026 at 8:39 PM lirongqing <lirongqing@baidu.com> wrote:
>
> From: Li RongQing <lirongqing@baidu.com>
>
> 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 <lirongqing@baidu.com>
> ---
>  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.

Thanks

>  }
>
>
> --
> 2.9.4
>

答复: [外部邮件] Re: [PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[Li,Rongqing]

> >
> > 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 <lirongqing@baidu.com>
> > ---
> >  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;

thanks
 
[Li,Rongqing] 


> Thanks
> 
> >  }
> >
> >
> > --
> > 2.9.4
> >

Re: 答复: [外部邮件] Re: [PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[Michael S. Tsirkin]

Eugenio, could you look at the qemu side of this pls?

On Fri, Sep 11, 2026 at 06:05:25AM +0000, Li,Rongqing 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 <lirongqing@baidu.com>
> > > ---
> > >  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;
> 
> thanks
>  
> [Li,Rongqing] 
> 
> 
> > Thanks
> > 
> > >  }
> > >
> > >
> > > --
> > > 2.9.4
> > >

Re: [外部邮件] Re: [PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[Eugenio Perez Martin]

On Fri, Sep 11, 2026 at 8:05 AM Li,Rongqing <lirongqing@baidu.com> 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 <lirongqing@baidu.com>
> > > ---
> > >  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?

Re: [外部邮件] Re: [PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[Michael S. Tsirkin]

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 <lirongqing@baidu.com> 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 <lirongqing@baidu.com>
> > > > ---
> > > >  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?

Re: [外部邮件] Re: [PATCH] virtio_ring: reset IN_ORDER state in virtqueue_init()

[Eugenio Perez Martin]

On Tue, Nov 3, 2026 at 10:41 AM Michael S. Tsirkin <mst@redhat.com> 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 <lirongqing@baidu.com> 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 <lirongqing@baidu.com>
> > > > > ---
> > > > >  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!