All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugenio Perez Martin <eperezma@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	Harpreet Singh Anand <hanand@xilinx.com>,
	 Stefano Garzarella <sgarzare@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>, Eli Cohen <eli@mellanox.com>,
	 Parav Pandit <parav@mellanox.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	 Zhu Lingshan <lingshan.zhu@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	 "Michael S. Tsirkin" <mst@redhat.com>,
	Cindy Lu <lulu@redhat.com>, Cornelia Huck <cohuck@redhat.com>,
	 Liuxiangdong <liuxiangdong5@huawei.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	Gautam Dawar <gdawar@xilinx.com>
Subject: Re: [RFC PATCH 01/12] vhost: Get vring base from vq, not svq
Date: Mon, 18 Jul 2022 09:14:36 +0200	[thread overview]
Message-ID: <CAJaqyWeDjT+fDRGch+qktRWeK_+qZPs7D3U5vNQMnmCCT5sUqA@mail.gmail.com> (raw)
In-Reply-To: <CACGkMEt_85xpsJiUTAu8kny4nEVJqHmBJzK2y5Zp5G_oUgXiFw@mail.gmail.com>

On Mon, Jul 18, 2022 at 7:48 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Sat, Jul 16, 2022 at 7:34 PM Eugenio Pérez <eperezma@redhat.com> wrote:
> >
> > The SVQ vring used idx usually match with the guest visible one, as long
> > as all the guest buffers (GPA) maps to exactly one buffer within qemu's
> > VA. However, as we can see in virtqueue_map_desc, a single guest buffer
> > could map to many buffers in SVQ vring.
> >
> > The solution is to stop using the device's used idx and check for the
> > last avail idx. Since we cannot report in-flight descriptors with vdpa,
> > let's rewind all of them.
> >
> > Fixes: 6d0b22266633 ("vdpa: Adapt vhost_vdpa_get_vring_base to SVQ")
> > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > ---
> >  hw/virtio/vhost-vdpa.c | 8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> > index 795ed5a049..18820498b3 100644
> > --- a/hw/virtio/vhost-vdpa.c
> > +++ b/hw/virtio/vhost-vdpa.c
> > @@ -1194,11 +1194,10 @@ static int vhost_vdpa_get_vring_base(struct vhost_dev *dev,
> >                                         struct vhost_vring_state *ring)
> >  {
> >      struct vhost_vdpa *v = dev->opaque;
> > -    int vdpa_idx = ring->index - dev->vq_index;
> >      int ret;
> >
> >      if (v->shadow_vqs_enabled) {
> > -        VhostShadowVirtqueue *svq = g_ptr_array_index(v->shadow_vqs, vdpa_idx);
> > +        VirtQueue *vq = virtio_get_queue(dev->vdev, ring->index);
> >
> >          /*
> >           * Setting base as last used idx, so destination will see as available
> > @@ -1208,7 +1207,10 @@ static int vhost_vdpa_get_vring_base(struct vhost_dev *dev,
> >           * TODO: This is ok for networking, but other kinds of devices might
> >           * have problems with these retransmissions.
> >           */
> > -        ring->num = svq->last_used_idx;
> > +        while (virtqueue_rewind(vq, 1)) {
> > +            continue;
> > +        }
>
> Will this leak mapped VirtQueueElement?
>

vhost_get_vring_base op is called only on the device's teardown path,
so they should be free by vhost_svq_stop.

However, you have a point that maybe vhost_get_vring_base should not
trust in that cleaning, even for -stable.

So I think it should be better to squash this and the next one as the
same fix. But it's doing two things at the same time: One of them is
to use the right state (as vring_base), and another one is not
reverting in-flight descriptors.

Thanks!

> Thanks
>
> > +        ring->num = virtio_queue_get_last_avail_idx(dev->vdev, ring->index);
> >          return 0;
> >      }
> >
> > --
> > 2.31.1
> >
>



  reply	other threads:[~2022-07-18  7:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-16 11:33 [RFC PATCH 00/12] NIC vhost-vdpa state restore via Shadow CVQ Eugenio Pérez
2022-07-16 11:33 ` [RFC PATCH 01/12] vhost: Get vring base from vq, not svq Eugenio Pérez
2022-07-18  5:48   ` Jason Wang
2022-07-18  7:14     ` Eugenio Perez Martin [this message]
2022-07-16 11:33 ` [RFC PATCH 02/12] vhost: Move SVQ queue rewind to the destination Eugenio Pérez
2022-07-18  5:49   ` Jason Wang
2022-07-18  7:20     ` Eugenio Perez Martin
2022-07-16 11:33 ` [RFC PATCH 03/12] vdpa: Small rename of error labels Eugenio Pérez
2022-07-18  5:50   ` Jason Wang
2022-07-18  7:21     ` Eugenio Perez Martin
2022-07-16 11:33 ` [RFC PATCH 04/12] vdpa: delay set_vring_ready after DRIVER_OK Eugenio Pérez
2022-07-18  6:34   ` Jason Wang
2022-07-18  6:57     ` Eugenio Perez Martin
2022-07-16 11:34 ` [RFC PATCH 05/12] vhost: stop transfer elem ownership in vhost_handle_guest_kick Eugenio Pérez
2022-07-16 11:34 ` [RFC PATCH 06/12] vhost: Use opaque data in SVQDescState Eugenio Pérez
2022-07-16 11:34 ` [RFC PATCH 07/12] vhost: Add VhostVDPAStartOp operation Eugenio Pérez
2022-07-17 11:01   ` Eugenio Perez Martin
2022-07-18  8:50   ` Jason Wang
2022-07-18  9:08     ` Eugenio Perez Martin
2022-07-16 11:34 ` [RFC PATCH 08/12] vdpa: Add vhost_vdpa_start_control_svq Eugenio Pérez
2022-07-16 11:34 ` [RFC PATCH 09/12] vdpa: Extract vhost_vdpa_net_svq_add from vhost_vdpa_net_handle_ctrl_avail Eugenio Pérez
2022-07-18  8:53   ` Jason Wang
2022-07-18 10:15     ` Eugenio Perez Martin
2022-07-16 11:34 ` [RFC PATCH 10/12] vdpa: Make vhost_vdpa_net_cvq_map_elem accept any out sg Eugenio Pérez
2022-07-16 11:34 ` [RFC PATCH 11/12] vdpa: Add virtio-net mac address via CVQ at start Eugenio Pérez
2022-07-18  8:55   ` Jason Wang
2022-07-18  9:07     ` Eugenio Perez Martin
2022-07-16 11:34 ` [RFC PATCH 12/12] vdpa: Delete CVQ migration blocker Eugenio Pérez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJaqyWeDjT+fDRGch+qktRWeK_+qZPs7D3U5vNQMnmCCT5sUqA@mail.gmail.com \
    --to=eperezma@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=armbru@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eli@mellanox.com \
    --cc=gdawar@xilinx.com \
    --cc=hanand@xilinx.com \
    --cc=jasowang@redhat.com \
    --cc=lingshan.zhu@intel.com \
    --cc=liuxiangdong5@huawei.com \
    --cc=lulu@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mst@redhat.com \
    --cc=parav@mellanox.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.