On Thu, Nov 10, 2016 at 08:16:38PM +0800, zhun...@gmail.com wrote:
> From this point of view ,I think it make sense well, thank you very much!
>  but I have another question about notify mechanism between virtIO driver and 
> qemu.
> according the source code of Linux and qemu,
> when driver add a sg buffer to send queue named sq,
> sq->vq->vring.avail->idx++
> vq->num_added++
> and then use virtqueue_kick_prepare to make sure if need notify qemu.
> it (new_idx-event_idx)<(new_idx-old_idx)

This expression is wrong.  The specification and Linux code both say:

  (u16)(new_idx - event_idx - 1) < (u16)(new_idx - old_idx)

Both the (u16) and the -1 matter.  Maybe that's why you are confused by
this?

> if it is true,then notify other side.
> However,every time driver add a sg,then virtqueue_kick_prepare is called,and 
> vq->num_added  is reseted to 0,so in fact ,I think vq->num_added is always 0 
> or 1。

A driver may add multiple buffers to the virtqueue by calling
virtqueue_add_sgs() or similar functions multiple times before kicking.
Therefore vq->num_added > 1 is possible.

> as to qemu side,every time when pop a elem from virtqueue,it set 
> VRingUsed.ring[vring.num] to the lastest VRingAvail.idx, this according the 
> arithmetic ((new_idx-event_idx)<(new_idx-old_idx)),it seems that this 
> mechanism does not make sense

You are basically asking "how does event_idx work?".  The specification
says:

  "The driver can ask the device to delay interrupts until an entry with
  an index specified by the “used_event” field is written in the used ring
  (equivalently, until the idx field in the used ring will reach the
  value used_event + 1)."

and:

  "The device can ask the driver to delay notifications until an entry
  with an index specified by the “avail_event” field is written in the
  available ring (equivalently, until the idx field in the used ring will
  reach the value avail_event + 1)."

Whenever the device or driver wants to notify, it first checks if the
index update crossed the event index set by the other side.

Attachment: signature.asc
Description: PGP signature

Reply via email to