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
