qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] virtIO question


From: address@hidden
Subject: Re: [Qemu-devel] virtIO question
Date: Sat, 12 Nov 2016 16:43:21 +0800

Thanks,the expression is not the key problem,I just write it wrong,the key 
problem is that what I get from the code is everytime dirver add a sg ,it will 
call virtqueue_kick,such as network driver,in start_xmit function ,it called 
xmit_skb generate a sg list and add it to the queue,then called virtqueue_kick 
,why it handle like this??can you explain it to me??thank you very much!!!



address@hidden
 
From: Stefan Hajnoczi
Date: 2016-11-11 20:03
To: address@hidden
CC: qemu
Subject: Re: Re: [Qemu-devel] virtIO question
On Thu, Nov 10, 2016 at 08:16:38PM +0800, address@hidden 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]