On Wed, Feb 14, 2024 at 1:39 PM Si-Wei Liu <si-wei....@oracle.com> wrote:
>
> Fix an issue where cancellation of ongoing migration ends up
> with no network connectivity.
>
> When canceling migration, SVQ will be switched back to the
> passthrough mode, but the right call fd is not programed to
> the device and the svq's own call fd is still used. At the
> point of this transitioning period, the shadow_vqs_enabled
> hadn't been set back to false yet, causing the installation
> of call fd inadvertently bypassed.
>
> Fixes: a8ac88585da1 ("vhost: Add Shadow VirtQueue call forwarding
> capabilities")
> Cc: Eugenio Pérez <epere...@redhat.com>
> Acked-by: Jason Wang <jasow...@redhat.com>
> Signed-off-by: Si-Wei Liu <si-wei....@oracle.com>
> ---
> hw/virtio/vhost-vdpa.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> index 004110f..dfeca8b 100644
> --- a/hw/virtio/vhost-vdpa.c
> +++ b/hw/virtio/vhost-vdpa.c
> @@ -1468,7 +1468,15 @@ static int vhost_vdpa_set_vring_call(struct vhost_dev
> *dev,
>
> /* Remember last call fd because we can switch to SVQ anytime. */
> vhost_svq_set_svq_call_fd(svq, file->fd);
> - if (v->shadow_vqs_enabled) {
> + /*
> + * When SVQ is transitioning to off, shadow_vqs_enabled has
> + * not been set back to false yet, but the underlying call fd
> + * will have to switch back to the guest notifier to signal the
> + * passthrough virtqueues. In other situations, SVQ's own call
> + * fd shall be used to signal the device model.
> + */
> + if (v->shadow_vqs_enabled &&
> + v->shared->svq_switching != SVQ_TSTATE_DISABLING) {
I think it would be great to not need to add more status variables to
vhost_vdpa (or any struct).
What if we recover the call file descriptor at vhost_vdpa_svqs_stop?
This way everything is more symmetrical as kick and call are set by
vhost_vdpa_svqs_start.
Thanks!
> return 0;
> }
>
> --
> 1.8.3.1
>
