[v3] Enable vdpa net migration with features depending on CVQ

[PATCH v3 0/5] Enable vdpa net migration with features depending on CVQ

Posted by Eugenio Pérez 8 months, 1 week ago

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

Re: [PATCH v3 0/5] Enable vdpa net migration with features depending on CVQ

Posted by Si-Wei Liu 7 months, 2 weeks ago

Does this series need to work with the recently merged 
ENABLE_AFTER_DRIVER_OK series from kernel?

-Siwei

On 8/22/2023 1:53 AM, Eugenio Pérez 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(-)
>
>
>

Re: [PATCH v3 0/5] Enable vdpa net migration with features depending on CVQ

Posted by Lei Yang 8 months, 1 week ago

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 <leiyang@redhat.com>


On Tue, Aug 22, 2023 at 4:53 PM Eugenio Pérez <eperezma@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
>
>