This series adds support for the VIRTIO_F_IN_ORDER feature flag to vhost shadow
virtqueue (SVQ), enabling migration of vDPA devices that offer this feature.
As SVQ acts as a virtio driver, the series follows the Linux kernel
implementation for the feature by Jason Wang.  This enables the live migration
of vhost-vdpa devices that supports IN_ORDER.

The IN_ORDER feature allows virtio devices to use many descriptors in batch,
just by marking the last one of the set as used.

The series is structured in three parts.  First, max_steps calculation in
virtqueue_ordered_fill is fixed to allow filling the entire virtqueue at once.
Otherwise, a full queue cannot be used with just one used entry.

Afterwards, the series extracts helper functions for descriptor processing to
prepare for in order changes:

Finally, the series adds IN_ORDER support, first adding conditional logic for
in-order vs regular processing and whitelisting the feature flag in SVQ.

Eugenio Pérez (7):
  virtio: Allow to fill a whole virtqueue in order
  vhost: move svq next desc array to descs state struct
  vhost: factor out the descriptor next fetching
  vhost: factor out the get of last used desc in SVQ
  vhost: factor out the detach buf logic in SVQ
  vhost: add in_order feature to shadow virtqueue
  vhost: accept in order feature flag

 hw/virtio/vhost-shadow-virtqueue.c | 215 +++++++++++++++++++++++++----
 hw/virtio/vhost-shadow-virtqueue.h |  38 ++++-
 hw/virtio/virtio.c                 |   2 +-
 3 files changed, 219 insertions(+), 36 deletions(-)

-- 
2.53.0

On 04.03.2026 20:35, Eugenio Pérez wrote:
> This series adds support for the VIRTIO_F_IN_ORDER feature flag to vhost shadow
> virtqueue (SVQ), enabling migration of vDPA devices that offer this feature.
> As SVQ acts as a virtio driver, the series follows the Linux kernel
> implementation for the feature by Jason Wang.  This enables the live migration
> of vhost-vdpa devices that supports IN_ORDER.
> 
> The IN_ORDER feature allows virtio devices to use many descriptors in batch,
> just by marking the last one of the set as used.
> 
> The series is structured in three parts.  First, max_steps calculation in
> virtqueue_ordered_fill is fixed to allow filling the entire virtqueue at once.
> Otherwise, a full queue cannot be used with just one used entry.
> 
> Afterwards, the series extracts helper functions for descriptor processing to
> prepare for in order changes:
> 
> Finally, the series adds IN_ORDER support, first adding conditional logic for
> in-order vs regular processing and whitelisting the feature flag in SVQ.
> 
> Eugenio Pérez (7):
>    virtio: Allow to fill a whole virtqueue in order
>    vhost: move svq next desc array to descs state struct
>    vhost: factor out the descriptor next fetching
>    vhost: factor out the get of last used desc in SVQ
>    vhost: factor out the detach buf logic in SVQ
>    vhost: add in_order feature to shadow virtqueue
>    vhost: accept in order feature flag
> 
>   hw/virtio/vhost-shadow-virtqueue.c | 215 +++++++++++++++++++++++++----
>   hw/virtio/vhost-shadow-virtqueue.h |  38 ++++-
>   hw/virtio/virtio.c                 |   2 +-

Hi!

This whole patchset is being Cc'ed to qemu-stable@.  Does this mean
that whole patch set should be picked up for the qemu stable series?
It's a rather unusual thing to do - to pick up new feature into a
stable series.  Is it what you have in mind?

Thanks,

/mjt

On Wed, Mar 11, 2026 at 12:50 PM Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> On 04.03.2026 20:35, Eugenio Pérez wrote:
> > This series adds support for the VIRTIO_F_IN_ORDER feature flag to vhost shadow
> > virtqueue (SVQ), enabling migration of vDPA devices that offer this feature.
> > As SVQ acts as a virtio driver, the series follows the Linux kernel
> > implementation for the feature by Jason Wang.  This enables the live migration
> > of vhost-vdpa devices that supports IN_ORDER.
> >
> > The IN_ORDER feature allows virtio devices to use many descriptors in batch,
> > just by marking the last one of the set as used.
> >
> > The series is structured in three parts.  First, max_steps calculation in
> > virtqueue_ordered_fill is fixed to allow filling the entire virtqueue at once.
> > Otherwise, a full queue cannot be used with just one used entry.
> >
> > Afterwards, the series extracts helper functions for descriptor processing to
> > prepare for in order changes:
> >
> > Finally, the series adds IN_ORDER support, first adding conditional logic for
> > in-order vs regular processing and whitelisting the feature flag in SVQ.
> >
> > Eugenio Pérez (7):
> >    virtio: Allow to fill a whole virtqueue in order
> >    vhost: move svq next desc array to descs state struct
> >    vhost: factor out the descriptor next fetching
> >    vhost: factor out the get of last used desc in SVQ
> >    vhost: factor out the detach buf logic in SVQ
> >    vhost: add in_order feature to shadow virtqueue
> >    vhost: accept in order feature flag
> >
> >   hw/virtio/vhost-shadow-virtqueue.c | 215 +++++++++++++++++++++++++----
> >   hw/virtio/vhost-shadow-virtqueue.h |  38 ++++-
> >   hw/virtio/virtio.c                 |   2 +-
>
> Hi!
>
> This whole patchset is being Cc'ed to qemu-stable@.  Does this mean
> that whole patch set should be picked up for the qemu stable series?
> It's a rather unusual thing to do - to pick up new feature into a
> stable series.  Is it what you have in mind?
>

Hi,

No, only the first patch. Sorry for not being clear, I thought it was
enough with the Fixes: tag, but thinking it twice I see how it might
not be clear enough. I'll make it clearer in the cover letter next
time, or is there a better way to handle this?

Thanks!

On 11.03.2026 15:24, Eugenio Perez Martin wrote:
> On Wed, Mar 11, 2026 at 12:50 PM Michael Tokarev <mjt@tls.msk.ru> wrote:

>> This whole patchset is being Cc'ed to qemu-stable@.  Does this mean
>> that whole patch set should be picked up for the qemu stable series?
>> It's a rather unusual thing to do - to pick up new feature into a
>> stable series.  Is it what you have in mind?

> No, only the first patch. Sorry for not being clear, I thought it was
> enough with the Fixes: tag, but thinking it twice I see how it might
> not be clear enough. I'll make it clearer in the cover letter next
> time, or is there a better way to handle this?

If not whole series should be picked up for stable, you can add
Cc: qemu-stable@.. to individual patches which should be.

The presence of Fixes: doesn't make it clear :)

But it's very good that you do care about stable series!

Thank you.  I've noted for this particular series, there's nothing
extra to do here.

Thanks,

/mjt