On Mon, Feb 27, 2023 at 8:15 AM Jason Wang <jasow...@redhat.com> wrote:
>
>
> 在 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 <epere...@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?).
>
This was actually an artifact of rebasing, sorry. This patch will be
removed fron v5 as there is already present in staging, commit
2e1a9de96b48 ("vdpa: stop all svq on device deletion").
Thanks!
