All of lore.kernel.org
 help / color / mirror / Atom feed
From: Si-Wei Liu <siwliu.kernel@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Eli Cohen <elic@nvidia.com>,
	mst@redhat.com, virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	lulu@redhat.com, Si-Wei Liu <si-wei.liu@oracle.com>
Subject: Re: [PATCH 1/2] vdpa/mlx5: Avoid unnecessary query virtqueue
Date: Mon, 1 Feb 2021 20:15:29 -0800	[thread overview]
Message-ID: <CAPWQSg3KOAypcrs9krW8cGE7EDLTehCUCYFZMUYYNaYPH1oBZQ@mail.gmail.com> (raw)
In-Reply-To: <9d6058d6-5ce1-0442-8fd9-5a6fe6a0bc6b@redhat.com>

On Mon, Feb 1, 2021 at 7:13 PM Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2021/2/2 上午3:17, Si-Wei Liu wrote:
> > On Mon, Feb 1, 2021 at 10:51 AM Si-Wei Liu <siwliu.kernel@gmail.com> wrote:
> >> On Thu, Jan 28, 2021 at 5:46 AM Eli Cohen <elic@nvidia.com> wrote:
> >>> suspend_vq should only suspend the VQ on not save the current available
> >>> index. This is done when a change of map occurs when the driver calls
> >>> save_channel_info().
> >> Hmmm, suspend_vq() is also called by teardown_vq(), the latter of
> >> which doesn't save the available index as save_channel_info() doesn't
> >> get called in that path at all. How does it handle the case that
> >> aget_vq_state() is called from userspace (e.g. QEMU) while the
> >> hardware VQ object was torn down, but userspace still wants to access
> >> the queue index?
> >>
> >> Refer to https://lore.kernel.org/netdev/1601583511-15138-1-git-send-email-si-wei.liu@oracle.com/
> >>
> >> vhost VQ 0 ring restore failed: -1: Resource temporarily unavailable (11)
> >> vhost VQ 1 ring restore failed: -1: Resource temporarily unavailable (11)
> >>
> >> QEMU will complain with the above warning while VM is being rebooted
> >> or shut down.
> >>
> >> Looks to me either the kernel driver should cover this requirement, or
> >> the userspace has to bear the burden in saving the index and not call
> >> into kernel if VQ is destroyed.
> > Actually, the userspace doesn't have the insights whether virt queue
> > will be destroyed if just changing the device status via set_status().
> > Looking at other vdpa driver in tree i.e. ifcvf it doesn't behave like
> > so. Hence this still looks to me to be Mellanox specifics and
> > mlx5_vdpa implementation detail that shouldn't expose to userspace.
>
>
> So I think we can simply drop this patch?

Yep, I think so. To be honest I don't know why it has anything to do
with the memory hotplug issue.

-Siwei

>
> Thanks
>
>
> >> -Siwei
> >>
> >>
> >>> Signed-off-by: Eli Cohen <elic@nvidia.com>
> >>> ---
> >>>   drivers/vdpa/mlx5/net/mlx5_vnet.c | 8 --------
> >>>   1 file changed, 8 deletions(-)
> >>>
> >>> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> >>> index 88dde3455bfd..549ded074ff3 100644
> >>> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> >>> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> >>> @@ -1148,8 +1148,6 @@ static int setup_vq(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *mvq)
> >>>
> >>>   static void suspend_vq(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *mvq)
> >>>   {
> >>> -       struct mlx5_virtq_attr attr;
> >>> -
> >>>          if (!mvq->initialized)
> >>>                  return;
> >>>
> >>> @@ -1158,12 +1156,6 @@ static void suspend_vq(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *m
> >>>
> >>>          if (modify_virtqueue(ndev, mvq, MLX5_VIRTIO_NET_Q_OBJECT_STATE_SUSPEND))
> >>>                  mlx5_vdpa_warn(&ndev->mvdev, "modify to suspend failed\n");
> >>> -
> >>> -       if (query_virtqueue(ndev, mvq, &attr)) {
> >>> -               mlx5_vdpa_warn(&ndev->mvdev, "failed to query virtqueue\n");
> >>> -               return;
> >>> -       }
> >>> -       mvq->avail_idx = attr.available_index;
> >>>   }
> >>>
> >>>   static void suspend_vqs(struct mlx5_vdpa_net *ndev)
> >>> --
> >>> 2.29.2
> >>>
>

  reply	other threads:[~2021-02-02  4:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 13:41 [PATCH 0/2] Fix failure to hot add memory Eli Cohen
2021-01-28 13:41 ` [PATCH 1/2] vdpa/mlx5: Avoid unnecessary query virtqueue Eli Cohen
2021-01-29  3:48   ` Jason Wang
2021-01-29  3:48     ` Jason Wang
2021-02-01 18:51   ` Si-Wei Liu
2021-02-01 19:17     ` Si-Wei Liu
2021-02-02  3:12       ` Jason Wang
2021-02-02  3:12         ` Jason Wang
2021-02-02  4:15         ` Si-Wei Liu [this message]
2021-02-02  6:02           ` Jason Wang
2021-02-02  6:02             ` Jason Wang
2021-02-02  7:06             ` Eli Cohen
2021-02-02  8:38               ` Si-Wei Liu
2021-02-02  9:22                 ` Eli Cohen
2021-02-02 17:54                   ` Si-Wei Liu
2021-02-03  5:16                     ` Jason Wang
2021-02-03  5:16                       ` Jason Wang
2021-02-03 23:19                       ` Si-Wei Liu
2021-02-04  2:57                         ` Jason Wang
2021-02-04  2:57                           ` Jason Wang
2021-02-04  6:53                         ` Eli Cohen
2021-02-02  7:00           ` Eli Cohen
2021-02-02 14:06             ` Michael S. Tsirkin
2021-02-02 14:06               ` Michael S. Tsirkin
2021-02-02  6:57         ` Eli Cohen
2021-01-28 13:41 ` [PATCH 2/2] vdpa/mlx5: Restore the hardware used index after change map Eli Cohen
2021-01-29  3:49   ` Jason Wang
2021-01-29  3:49     ` Jason Wang
2021-01-31 18:55     ` Eli Cohen
2021-02-01  3:36       ` Jason Wang
2021-02-01  3:36         ` Jason Wang
2021-02-01  5:52         ` Eli Cohen
2021-02-01  6:00           ` Jason Wang
2021-02-01  6:00             ` Jason Wang
2021-02-01  6:38             ` Eli Cohen
2021-02-01  7:23               ` Jason Wang
2021-02-01  7:23                 ` Jason Wang

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=CAPWQSg3KOAypcrs9krW8cGE7EDLTehCUCYFZMUYYNaYPH1oBZQ@mail.gmail.com \
    --to=siwliu.kernel@gmail.com \
    --cc=elic@nvidia.com \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=si-wei.liu@oracle.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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.