All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	rob.miller@broadcom.com, lingshan.zhu@intel.com,
	eperezma@redhat.com, lulu@redhat.com, shahafs@mellanox.com,
	hanand@xilinx.com, mhabets@solarflare.com, gdawar@xilinx.com,
	saugatm@xilinx.com, vmireyno@marvell.com,
	zhangweining@ruijie.com.cn, eli@mellanox.com
Subject: Re: [PATCH 1/6] vhost: allow device that does not depend on vhost worker
Date: Tue, 2 Jun 2020 15:04:08 +0800	[thread overview]
Message-ID: <21e1bfbf-4b0c-5a73-6fdd-a58c43c733ea@redhat.com> (raw)
In-Reply-To: <20200602005904-mutt-send-email-mst@kernel.org>


On 2020/6/2 下午1:01, Michael S. Tsirkin wrote:
> On Fri, May 29, 2020 at 04:02:58PM +0800, Jason Wang wrote:
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index d450e16c5c25..70105e045768 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -166,11 +166,16 @@ static int vhost_poll_wakeup(wait_queue_entry_t *wait, unsigned mode, int sync,
>>   			     void *key)
>>   {
>>   	struct vhost_poll *poll = container_of(wait, struct vhost_poll, wait);
>> +	struct vhost_work *work = &poll->work;
>>   
>>   	if (!(key_to_poll(key) & poll->mask))
>>   		return 0;
>>   
>> -	vhost_poll_queue(poll);
>> +	if (!poll->dev->use_worker)
>> +		work->fn(work);
>> +	else
>> +		vhost_poll_queue(poll);
>> +
>>   	return 0;
>>   }
>>
> So a wakeup function wakes up eventfd directly.
>
> What if user supplies e.g. the same eventfd as ioeventfd?
>
> Won't this cause infinite loops?


I'm not sure I get this.

This basically calls handle_vq directly when eventfd is woken up. The 
infinite loops can only happen when handle_vq() tries to write to 
ioeventfd itslef which should be a bug of the device.

Thanks


>


WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: shahafs@mellanox.com, lulu@redhat.com, kvm@vger.kernel.org,
	saugatm@xilinx.com, netdev@vger.kernel.org,
	mhabets@solarflare.com, vmireyno@marvell.com,
	linux-kernel@vger.kernel.org, gdawar@xilinx.com,
	virtualization@lists.linux-foundation.org, eperezma@redhat.com,
	hanand@xilinx.com, zhangweining@ruijie.com.cn, eli@mellanox.com,
	lingshan.zhu@intel.com, rob.miller@broadcom.com
Subject: Re: [PATCH 1/6] vhost: allow device that does not depend on vhost worker
Date: Tue, 2 Jun 2020 15:04:08 +0800	[thread overview]
Message-ID: <21e1bfbf-4b0c-5a73-6fdd-a58c43c733ea@redhat.com> (raw)
In-Reply-To: <20200602005904-mutt-send-email-mst@kernel.org>


On 2020/6/2 下午1:01, Michael S. Tsirkin wrote:
> On Fri, May 29, 2020 at 04:02:58PM +0800, Jason Wang wrote:
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index d450e16c5c25..70105e045768 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -166,11 +166,16 @@ static int vhost_poll_wakeup(wait_queue_entry_t *wait, unsigned mode, int sync,
>>   			     void *key)
>>   {
>>   	struct vhost_poll *poll = container_of(wait, struct vhost_poll, wait);
>> +	struct vhost_work *work = &poll->work;
>>   
>>   	if (!(key_to_poll(key) & poll->mask))
>>   		return 0;
>>   
>> -	vhost_poll_queue(poll);
>> +	if (!poll->dev->use_worker)
>> +		work->fn(work);
>> +	else
>> +		vhost_poll_queue(poll);
>> +
>>   	return 0;
>>   }
>>
> So a wakeup function wakes up eventfd directly.
>
> What if user supplies e.g. the same eventfd as ioeventfd?
>
> Won't this cause infinite loops?


I'm not sure I get this.

This basically calls handle_vq directly when eventfd is woken up. The 
infinite loops can only happen when handle_vq() tries to write to 
ioeventfd itslef which should be a bug of the device.

Thanks


>

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

  reply	other threads:[~2020-06-02  7:04 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29  8:02 [PATCH 0/6] vDPA: doorbell mapping Jason Wang
2020-05-29  8:02 ` Jason Wang
2020-05-29  8:02 ` [PATCH 1/6] vhost: allow device that does not depend on vhost worker Jason Wang
2020-05-29  8:02   ` Jason Wang
2020-06-02  5:01   ` Michael S. Tsirkin
2020-06-02  7:04     ` Jason Wang [this message]
2020-06-02  7:04       ` Jason Wang
2020-05-29  8:02 ` [PATCH 2/6] vhost: use mmgrab() instead of mmget() for non worker device Jason Wang
2020-05-29  8:03 ` [PATCH 3/6] vdpa: introduce get_vq_notification method Jason Wang
2020-05-29  8:03   ` Jason Wang
2020-05-29  8:03 ` [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap Jason Wang
2020-05-29  9:16   ` Mika Penttilä
2020-05-29  9:24     ` Jason Wang
2020-05-29 18:30   ` Rob Miller
2020-05-29 18:30     ` [virtio-dev] " Rob Miller
2020-06-02  2:04     ` Jason Wang
2020-06-02  2:04       ` Jason Wang
2020-06-02  2:04       ` Jason Wang
2020-06-01 19:22   ` kbuild test robot
2020-06-01 19:22     ` kbuild test robot
2020-06-01 19:22     ` kbuild test robot
2020-06-02  4:56     ` Michael S. Tsirkin
2020-06-02  4:56       ` Michael S. Tsirkin
2020-06-02  6:49       ` Jason Wang
2020-06-02  6:49         ` Jason Wang
2020-06-02 13:31         ` Michael S. Tsirkin
2020-06-02 13:31           ` Michael S. Tsirkin
2020-06-03  4:18           ` Jason Wang
2020-06-03  4:18             ` Jason Wang
2020-06-03  6:34             ` Michael S. Tsirkin
2020-06-03  6:34               ` Michael S. Tsirkin
2020-06-03  6:37               ` Jason Wang
2020-06-03  6:37                 ` Jason Wang
2020-05-29  8:03 ` [PATCH 5/6] vdpa: introduce virtio pci driver Jason Wang
2020-05-29  8:03   ` Jason Wang
2020-06-02  5:08   ` Michael S. Tsirkin
2020-06-02  7:08     ` Jason Wang
2020-06-05  8:54       ` Jason Wang
2020-06-05  8:54         ` Jason Wang
2020-06-07 13:51         ` Michael S. Tsirkin
2020-06-07 13:51           ` Michael S. Tsirkin
2020-06-08  3:32           ` Jason Wang
2020-06-08  3:32             ` Jason Wang
2020-06-08  6:32             ` Michael S. Tsirkin
2020-06-08  9:18               ` Jason Wang
2020-06-08  9:31                 ` Michael S. Tsirkin
2020-06-08  9:43                   ` Jason Wang
2020-06-08  9:45                     ` Michael S. Tsirkin
2020-06-08  9:45                       ` Michael S. Tsirkin
2020-06-08  9:46                       ` Jason Wang
2020-06-08  9:54                         ` Michael S. Tsirkin
2020-06-08 10:07                           ` Jason Wang
2020-06-08 13:29                             ` Michael S. Tsirkin
2020-06-08 13:29                               ` Michael S. Tsirkin
2020-06-09  5:55                               ` Jason Wang
2020-06-02  5:09   ` Michael S. Tsirkin
2020-06-02  7:12     ` Jason Wang
2020-06-04 18:50       ` Michael S. Tsirkin
2020-05-29  8:03 ` [PATCH 6/6] vdpa: vp_vdpa: report doorbell location Jason Wang
2020-05-29  8:03   ` 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=21e1bfbf-4b0c-5a73-6fdd-a58c43c733ea@redhat.com \
    --to=jasowang@redhat.com \
    --cc=eli@mellanox.com \
    --cc=eperezma@redhat.com \
    --cc=gdawar@xilinx.com \
    --cc=hanand@xilinx.com \
    --cc=kvm@vger.kernel.org \
    --cc=lingshan.zhu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mhabets@solarflare.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rob.miller@broadcom.com \
    --cc=saugatm@xilinx.com \
    --cc=shahafs@mellanox.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=vmireyno@marvell.com \
    --cc=zhangweining@ruijie.com.cn \
    /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.