[dpdk-dev] [PATCH v2] vhost: Fix default value of kickfd and callfd

Yuanhan Liu yuanhan.liu at linux.intel.com
Mon Mar 14 03:08:58 CET 2016


On Mon, Mar 14, 2016 at 10:54:14AM +0900, Tetsuya Mukawa wrote:
> On 2016/03/11 16:19, Yuanhan Liu wrote:
> > On Thu, Mar 10, 2016 at 04:06:05PM +0900, Tetsuya Mukawa wrote:
> >> Currently, default values of kickfd and callfd are -1.
> >> If the values are -1, current code guesses kickfd and callfd haven't
> >> been initialized yet. And vhost library will guess the virtqueue isn't
> >> ready for processing.
> >> But callfd and kickfd will be set as -1 when "--enable-kvm"
> >> isn't specified in QEMU command line. It means we cannot treat -1 as
> >> uninitialized state. The patch changes default values to -2. And the
> >> patch defines -2 as VIRTIO_UNINITIALIZED_EVENTFD.
> > This looks more like a workaround to me. 
> 
> 
> Hi Yuanhan,
> 
> Sorry for late reply.
> I have checked QEMU documentation, and found below.
> 
> ----------
>  * VHOST_USER_SET_VRING_CALL
> 
>       Id: 14
>       Equivalent ioctl: VHOST_SET_VRING_CALL
>       Master payload: u64
> 
>       Set the event file descriptor to signal when buffers are used. It
>       is passed in the ancillary data.
>       Bits (0-7) of the payload contain the vring index. Bit 8 is the
>       invalid FD flag.
> ----------
> 
> VHOST_USER_SET_VRING_KICK has almost same description.
> I will check this invalid flag, and if it works for our case, then will
> use it.
> How about it?

Yeah, that indeed sounds much better.

	--yliu

> 
> > Besides, this patch would make
> > following fail:
> >
> >     eventfd_write(vq->callfd, (eventfd_t)1);
> 
> It's my fault.
> I thought above case should be blocked by virtio spec itself. So just
> leave it.
> But eventfd is came from vhost spec, so VRING_AVAIL_F_NO_INTERRUPT might
> be set even when kickfd and callfd are -1.
> Thanks for checking it.
> 
> Tetsuya
> 
> > 	--yliu


More information about the dev mailing list