[Qemu-devel] virtIO question
who can explain the means of idx in VRingUsed and VRingAvail structure about virtIO?? thanks! zhun...@gmail.com
Re: [Qemu-devel] virtIO question
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?? zhun...@gmail.com From: jitendra kumar khasdev Date: 2016-11-05 23:41 To: Peter Maydell CC: zhun...@gmail.com; qemu-devel Subject: Re: [Qemu-devel] virtIO question Have you looked at the virtio specification? No. This describes the overall structure and communication mechanism, which QEMU and Linux each only implement one half of: http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html Thanks Peter. This doc looks me interesting. --- Jitendra
Re: [Qemu-devel] virtIO question
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! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-10 18:32 To: zhun...@gmail.com CC: jkhasdev; qemu Subject: Re: [Qemu-devel] virtIO question On Wed, Nov 09, 2016 at 06:58:16PM +0800, zhun...@gmail.com 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.
Re: [Qemu-devel] virtIO question
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!!! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-11 20:03 To: zhun...@gmail.com CC: qemu Subject: Re: Re: [Qemu-devel] virtIO question 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.
Re: [Qemu-devel] virtIO question
Hello，teacher,I may be found where the driver add mutiple buffer to virtqueue and then kick qemu side. It is when driver use NAPI to poll the device to get buffers,and it is in receive queue.but in transmit queue,every time driver add a buffer to virtqueue,then kick function is called!!!why ??is qemu handle buffer faster than driver add it?? thank you very much! zhun...@gmail.com From: Stefan Hajnoczi Date: 2016-11-11 20:03 To: zhun...@gmail.com CC: qemu Subject: Re: Re: [Qemu-devel] virtIO question 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.
[Qemu-devel] virtIO question
I have a question about qemu.is it a bug in qemu version 1.2?
in qemu version 1.2 ,it set avail event by the code :
if (vq->vdev->guest_features & (1 << VIRTIO_RING_F_EVENT_IDX)) {
vring_avail_event(vq, vring_avail_idx(vq));
}
and in version 2.7 the code is
if (virtio_vdev_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX)) {
vring_set_avail_event(vq, vq->last_avail_idx);
}
a big difference of this is the value.vring_avail_idx(vq)is the latest value of
VRingAvail.idx,and vq->last_avail_idx is not, I think it really different with
the two different values,and I think the later is right,is it??
thanks a lot!!
zhun...@gmail.com
[Qemu-devel] help!
Hello，recently I study qemu source code ,and I have some questions ,can you
help me ?
> 1、what is the meaning of queues in structure NICConf ? I think it is the
> number of queues to a NIC,and I do not where it is.
> 2、In NICConf init Function，I do not found it initulize the queues of
> NICConf，relative code is
>
> #define DEFINE_NIC_PROPERTIES(_state, _conf)\
> DEFINE_PROP_MACADDR("mac", _state, _conf.macaddr),\
> DEFINE_PROP_VLAN("vlan", _state, _conf.peers), \
> DEFINE_PROP_NETDEV("netdev", _state, _conf.peers), \
> DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1)
>
> 3、when new a NIC,I found conf->peers.ncs is a pointer which point a
> NetClientState array,I want to know what the array stand for?hub ports?
zhun...@gmail.com
