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: Thu, 10 Nov 2016 20:16:38 +0800

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)
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。
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
I do not know if I describe it clearly.or can you give me an example to prove 
how it make sense!!
thanks a lot!


address@hidden
 
From: Stefan Hajnoczi
Date: 2016-11-10 18:32
To: address@hidden
CC: jkhasdev; qemu
Subject: Re: [Qemu-devel] virtIO question
On Wed, Nov 09, 2016 at 06:58:16PM +0800, address@hidden wrote:
> I want to ask a another question,why a virt_queue in virtio include in_sgs 
> and out_sgs,for example,send_queue of virtIO net driver have in_sgs and 
> out_sgs,when transmit data,It add buffer to out_sgs of send_queue,but how it 
> to use in_sgs??
 
You can think of every virtqueue buffer as having two scatter-gather
lists:
1. out_sgs are driver->device buffers (e.g. tx packet payload)
2. in_sgs are device->driver buffers (e.g. rx packet payload)
 
Look at the virtio-net ctrl virtqueue (see spec and
virtio_net_handle_ctrl() for details).  Each buffer has:
 
1. struct virtio_net_ctrl_hdr (out_sgs)
2. request-specific fields (out_sgs)
3. virtio_net_ctrl_ack status byte (in_sgs)
 
The device parses the request and performs the operation.  Then it fills
in the result (success or error code) in the status byte.
 
Processing ctrl virtqueue buffers therefore requires both guest memory
reads (out_sgs) and writes (in_sgs).  Most of the other virtio devices
also use bi-directional buffers.
 
This may not be obvious if you only consider the virtio-net tx
virtqueue, for example, where buffers use out_sgs only.
 
Hope this makes sense.  If not, look at the specification again and
think about how virtio-net ctrl request processing works.

reply via email to

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