QE tested this series with MAC and MQ changes, and the guest migrated
successfully with "x-svq=off" or without this parameter.
Tested-by: Lei Yang <leiy...@redhat.com>
On Tue, Aug 22, 2023 at 4:53 PM Eugenio Pérez <epere...@redhat.com> wrote:
>
> At this moment the migration of net features that depends on CVQ is not
> possible, as there is no reliable way to restore the device state like mac
> address, number of enabled queues, etc to the destination. This is mainly
> caused because the device must only read CVQ, and process all the commands
> before resuming the dataplane.
>
> This series lift that requirement, sending the VHOST_VDPA_SET_VRING_ENABLE
> ioctl for dataplane vqs only after the device has processed all commands.
> ---
> v3:
> * Fix subject typo and expand message of patch ("vdpa: move
> vhost_vdpa_set_vring_ready to the caller").
>
> v2:
> * Factor out VRING_ENABLE ioctls from vhost_vdpa_dev_start to the caller,
> instead of providing a callback to know if it must be called or not.
> * at https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg05447.html
>
> RFC:
> * Enable vqs early in case CVQ cannot be shadowed.
> * at https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg01325.html
>
> Eugenio Pérez (5):
> vdpa: use first queue SVQ state for CVQ default
> vdpa: export vhost_vdpa_set_vring_ready
> vdpa: rename vhost_vdpa_net_load to vhost_vdpa_net_cvq_load
> vdpa: move vhost_vdpa_set_vring_ready to the caller
> vdpa: remove net cvq migration blocker
>
> include/hw/virtio/vhost-vdpa.h | 1 +
> hw/virtio/vdpa-dev.c | 3 ++
> hw/virtio/vhost-vdpa.c | 22 +++++-----
> net/vhost-vdpa.c | 75 +++++++++++++++++++---------------
> hw/virtio/trace-events | 2 +-
> 5 files changed, 57 insertions(+), 46 deletions(-)
>
> --
> 2.39.3
>
>
