I have managed to deal with it.
The thing is I was using one of the latest versions of qemu, but an
old Linux Kernel version of 3.12.
On Thu, Jul 9, 2015 at 1:43 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote:
> On Tue, Jul 07, 2015 at 02:43:06PM +0300, Catalin Vasile wrote:
>> My vhost module respects the format vhost-net uses:
>>
>> /* <code> summary */
>> mutex_lock(&vq->mutex);
>> vhost_disable_notify();
>> for (;;) {
>> head = vhost_get_vq_desc();
>> if (head == vq->num) {
>> if (unlikely(vhost_enable_notify())) {
>> vhost_disable_notify();
>> continue;
>> }
>> break;
>> }
>> vhost_add_used_and_signal();
>> }
>> mutex_unlock(&vq->mutex);
>> /* </code> */
>>
>> I have made a lot of printk() calls and the first job gets processed
>> completely, and gets through all those calls:
>> 1. it goes into a first loop and processes the first job (get
>> descriptor, work with the descriptor, add used and signal).
>> 2. On the second loop it hits head == vq->num, and goes back to
>> listening to notifications (successfully, it does not get into the
>> fallback).
>>
>> Now in the guest:
>> 1. sends first job and the paramers used to call vring_need_event() are:
>> vring_avail_event=0, new=1, old=0 (which makes the function evaluate to "0 <
>> 1")
>> 2. the queue is kicked and vhost does its job.
>> 3. the guest driver reaches the end of the first job, and lets the
>> following job take its course, only this time vring_need_event()
>> receives the following parameters:
>> vring_avail_event=0, new=2, old=1 (which makes the function evaluate to "1 <
>> 1")
>
> This means you need to look at the vhost code because vring_avail_event
> shouldn't be 0.
>
> Why wasn't vhost_update_avail_event() called?
>
> Maybe the feature bit negotiation for your device is broken and vhost
> thinks VIRTIO_RING_F_EVENT_IDX is not set.
>
> Or does the used ring have the VRING_USED_F_NO_NOTIFY flag?
