Re: [PATCH v3 09/11] vduse: Signal interrupt's eventfd directly in vhost-vdpa case

From: Jason Wang <jasowang@redhat.com>
To: Xie Yongji <xieyongji@bytedance.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
	virtualization@lists.linux-foundation.org, hch@lst.de,
	mst@redhat.com
Subject: Re: [PATCH v3 09/11] vduse: Signal interrupt's eventfd directly in vhost-vdpa case
Date: Thu, 16 Mar 2023 17:30:36 +0800	[thread overview]
Message-ID: <CACGkMEsaeAJbTzx0M3DJzt=dwWyWvX79L1tapfZ1O-AKyG73Mw@mail.gmail.com> (raw)
In-Reply-To: <20230228094110.37-10-xieyongji@bytedance.com>

On Tue, Feb 28, 2023 at 5:42 PM Xie Yongji <xieyongji@bytedance.com> wrote:
>
> Now the vdpa callback will associate an eventfd in
> vhost-vdpa case.

I'd suggest avoiding mentioning drivers since vDPA parents should not
know which vDPA driver is bound.

We could say "signal vq trigger eventfd directly if possible"?

With those tweaked.

Acked-by: Jason Wang <jasowang@redhat.com>

Thanks

> For performance reasons, VDUSE can
> signal it directly during irq injection.
>
> Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> ---
>  drivers/vdpa/vdpa_user/vduse_dev.c | 27 +++++++++++++++++++++++----
>  1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> index 869cc7860d82..56f3c2480c2a 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -461,6 +461,7 @@ static void vduse_dev_reset(struct vduse_dev *dev)
>                 spin_lock(&vq->irq_lock);
>                 vq->cb.callback = NULL;
>                 vq->cb.private = NULL;
> +               vq->cb.irq_ctx = NULL;
>                 spin_unlock(&vq->irq_lock);
>                 flush_work(&vq->inject);
>                 flush_work(&vq->kick);
> @@ -526,6 +527,7 @@ static void vduse_vdpa_set_vq_cb(struct vdpa_device *vdpa, u16 idx,
>         spin_lock(&vq->irq_lock);
>         vq->cb.callback = cb->callback;
>         vq->cb.private = cb->private;
> +       vq->cb.irq_ctx = cb->irq_ctx;
>         spin_unlock(&vq->irq_lock);
>  }
>
> @@ -1020,6 +1022,20 @@ static void vduse_vq_irq_inject(struct work_struct *work)
>         spin_unlock_irq(&vq->irq_lock);
>  }
>
> +static bool vduse_vq_signal_irqfd(struct vduse_virtqueue *vq)
> +{
> +       bool signal = false;
> +
> +       spin_lock_irq(&vq->irq_lock);
> +       if (vq->ready && vq->cb.irq_ctx) {
> +               eventfd_signal(vq->cb.irq_ctx, 1);
> +               signal = true;
> +       }
> +       spin_unlock_irq(&vq->irq_lock);
> +
> +       return signal;
> +}
> +
>  static int vduse_dev_queue_irq_work(struct vduse_dev *dev,
>                                     struct work_struct *irq_work,
>                                     int irq_effective_cpu)
> @@ -1322,11 +1338,14 @@ static long vduse_dev_ioctl(struct file *file, unsigned int cmd,
>                 if (index >= dev->vq_num)
>                         break;
>
> +               ret = 0;
>                 index = array_index_nospec(index, dev->vq_num);
> -
> -               vduse_vq_update_effective_cpu(dev->vqs[index]);
> -               ret = vduse_dev_queue_irq_work(dev, &dev->vqs[index]->inject,
> -                                       dev->vqs[index]->irq_effective_cpu);
> +               if (!vduse_vq_signal_irqfd(dev->vqs[index])) {
> +                       vduse_vq_update_effective_cpu(dev->vqs[index]);
> +                       ret = vduse_dev_queue_irq_work(dev,
> +                                               &dev->vqs[index]->inject,
> +                                               dev->vqs[index]->irq_effective_cpu);
> +               }
>                 break;
>         }
>         case VDUSE_IOTLB_REG_UMEM: {
> --
> 2.20.1
>

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization