Virtualization - Feb 2023 - [PATCH v4 03/15] vdpa: stop svq at vhost_vdpa_dev_start(false)

? 2023/2/24 23:54, Eugenio P?rez ??:
> It used to be done at vhost_vdpa_svq_cleanup, since a device couldn't
> switch to SVQ mode dynamically.  Now that we need to fetch the state and
> trust SVQ will not modify guest's used_idx at migration, stop
> effectively SVQ at suspend time, as a real device would do.
>
> Leaving old vhost_svq_stop call at vhost_vdpa_svq_cleanup, as its
> supported to call it many times and it follows other operations that are
> called redundantly there too:
> * vhost_vdpa_host_notifiers_uninit
> * memory_listener_unregister
>
> Signed-off-by: Eugenio P?rez <eperezma at redhat.com>
> ---
> v3: New in v3
> ---
>   hw/virtio/vhost-vdpa.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> index 4f72a52a43..d9260191cc 100644
> --- a/hw/virtio/vhost-vdpa.c
> +++ b/hw/virtio/vhost-vdpa.c
> @@ -1100,10 +1100,11 @@ static void vhost_vdpa_svqs_stop(struct vhost_dev
*dev)
>   
>       for (unsigned i = 0; i < v->shadow_vqs->len; ++i) {
>           VhostShadowVirtqueue *svq = g_ptr_array_index(v->shadow_vqs,
i);
> +
> +        vhost_svq_stop(svq);
>           vhost_vdpa_svq_unmap_rings(dev, svq);
>   
>           event_notifier_cleanup(&svq->hdev_kick);
> -        event_notifier_cleanup(&svq->hdev_call);

Any reason we need to not clean callfd? (Not explained in the change 
log, or should be another patch?).

Thanks

>       }
>   }
>