On Wed, Apr 17, 2013 at 04:27:13PM +0800, Jason Wang wrote: > On 04/17/2013 03:20 PM, Aurelien Jarno wrote: > > On Tue, Apr 16, 2013 at 11:08:59AM +0800, Jason Wang wrote: > >> On 04/15/2013 04:28 PM, Aurelien Jarno wrote: > >>> On Mon, Apr 15, 2013 at 01:29:01PM +0800, Jason Wang wrote: > >>>> On 04/13/2013 09:17 PM, Aurelien Jarno wrote: > >>>>> On Fri, Jan 25, 2013 at 06:35:41PM +0800, Jason Wang wrote: > >>>>>> This patch implements both userspace and vhost support for multiple > >>>>>> queue > >>>>>> virtio-net (VIRTIO_NET_F_MQ). This is done by introducing an array of > >>>>>> VirtIONetQueue to VirtIONet. > >>>>>> > >>>>>> Signed-off-by: Jason Wang <jasow...@redhat.com> > >>>>>> --- > >>>>>> hw/virtio-net.c | 317 > >>>>>> +++++++++++++++++++++++++++++++++++++++++++------------ > >>>>>> hw/virtio-net.h | 28 +++++- > >>>>>> 2 files changed, 275 insertions(+), 70 deletions(-) > >>>>> This patch breaks virtio-net in Minix, even with multiqueue disable. I > >>>>> don't know virtio enough to know if it is a Minix or a QEMU problem. > >>>>> However I have been able to identify the part of the commit causing the > >>>>> failure: > >>>> Hi Aurelien: > >>>> > >>>> Thanks for the work. > >>>>>> diff --git a/hw/virtio-net.c b/hw/virtio-net.c > >>>>>> index ef522d5..cec91a7 100644 > >>>>>> --- a/hw/virtio-net.c > >>>>>> +++ b/hw/virtio-net.c > >>>>> ... > >>>>> > >>>>>> +static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, > >>>>>> int ctrl) > >>>>>> +{ > >>>>>> + VirtIODevice *vdev = &n->vdev; > >>>>>> + int i, max = multiqueue ? n->max_queues : 1; > >>>>>> + > >>>>>> + n->multiqueue = multiqueue; > >>>>>> + > >>>>>> + for (i = 2; i <= n->max_queues * 2 + 1; i++) { > >>>>>> + virtio_del_queue(vdev, i); > >>>>>> + } > >>>>>> + > >>>>> The for loop above is something which is new, even with multiqueue > >>>>> disabled. Even with max_queues=1 it calls virtio_del_queue with i = 2 > >>>>> and i = 3. Disabling this loop makes the code to work as before. > >>>> Looks like a bug here, need to change n->max_queues * 2 + 1 to > >>>> n->max_queues * 2. The reason we need to del queue 2 each time because > >>>> vq 2 has different meaning is multiqueue and single queue. In single > >>>> queue, vq 2 maybe ctrl vq, but in multiqueue mode it was rx1. > >>>> > >>>> Let's see whether this small change works. > >>> Unfortunately it doesn't fix the issue. I don't know a lot about virtio, > >>> but would it be possible to only delete the queue that have been > >>> enabled? > >> The issue is vq 2 has different meanings in two modes, so it must be > >> deleted and reinitialized during feature negotiation. > >>>>> On the Minix side it triggers the following assertion: > >>>>> > >>>>> | virtio.c:370: assert "q->vaddr != NULL" failed, function > >>>>> "free_phys_queue" > >>>>> > >>>>> > >>>>> | virtio_net(73141): panic: assert failed > >>>>> > >>>>> This correspond to this function in lib/libvirtio/virtio.c: > >>>>> > >>>>> | static void > >>>>> | free_phys_queue(struct virtio_queue *q) > >>>>> | { > >>>>> | assert(q != NULL); > >>>>> | assert(q->vaddr != NULL); > >>>>> | > >>>>> | free_contig(q->vaddr, q->ring_size); > >>>>> | q->vaddr = NULL; > >>>>> | q->paddr = 0; > >>>>> | q->num = 0; > >>>>> | free_contig(q->data, sizeof(q->data[0])); > >>>>> | q->data = NULL; > >>>>> | } > >>>>> > >>>>> Do you have an idea if the problem is on the Minix side or on the QEMU > >>>>> side? > >>>>> > >>>> Haven't figured out the relationship between virtqueue dynamic del/add > >>>> and q->vaddr here. If the above changes does not work, I guess this > >>> Unfortunately I don't really know the minix code either. I happen to > >>> found the issue when testing other changes, and looked at the code to > >>> try to understand the problem. > >> Me too. > >>>> problem happens only for ctrl vq (vq2)? And when does this happen? > >>> I guess so given removing the call to virtio_del_queue() for vq2 fixes > >>> or workarounds the issue. > >> It will cause trouble for multiqueue guest who may think vq2 is rx queue. > >>>> Rebooting? > >>> It happens at the initial boot. > >> Looks at the codes, looks like vq2 was initialized unconditionally at > >> start, how about the following patch? > >> > >> diff --git a/hw/virtio-net.c b/hw/virtio-net.c > >> index 4bb49eb..4886aa0 100644 > >> --- a/hw/virtio-net.c > >> +++ b/hw/virtio-net.c > >> @@ -1300,7 +1300,6 @@ VirtIODevice *virtio_net_init(DeviceState *dev, > >> NICConf *conf, > >> virtio_net_handle_tx_bh); > >> n->vqs[0].tx_bh = qemu_bh_new(virtio_net_tx_bh, &n->vqs[0]); > >> } > >> - n->ctrl_vq = virtio_add_queue(&n->vdev, 64, virtio_net_handle_ctrl); > >> qemu_macaddr_default_if_unset(&conf->macaddr); > >> memcpy(&n->mac[0], &conf->macaddr, sizeof(n->mac)); > >> n->status = VIRTIO_NET_S_LINK_UP; > >> > > Unfortunately this patch doesn't work, I tried it with and without your > > previous suggested change (max_queues * 2 + 1) => max_queues * 2. > > > > Aurelien > > > > Thanks for the test, I will try to get a minix to see what happens and > keep you updated. >
Thanks! I have used minix 3.2.1 which include virtio drivers. See the following page, step 5 to know how to enable virtio: http://wiki.minix3.org/en/UsersGuide/RunningOnQemu -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net