From patchwork Mon Jan 2 05:19:17 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ying-Shiuan Pan X-Patchwork-Id: 133795 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 8A66AB6FA2 for ; Mon, 2 Jan 2012 16:19:53 +1100 (EST) Received: from localhost ([::1]:48703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhaJH-0004WF-Ly for incoming@patchwork.ozlabs.org; Mon, 02 Jan 2012 00:19:47 -0500 Received: from eggs.gnu.org ([140.186.70.92]:39369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhaJB-0004W4-6q for qemu-devel@nongnu.org; Mon, 02 Jan 2012 00:19:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhaJ9-0007zF-Df for qemu-devel@nongnu.org; Mon, 02 Jan 2012 00:19:41 -0500 Received: from mail-tul01m020-f173.google.com ([209.85.214.173]:33521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhaJ9-0007z2-A5 for qemu-devel@nongnu.org; Mon, 02 Jan 2012 00:19:39 -0500 Received: by obcwp18 with SMTP id wp18so12587572obc.4 for ; Sun, 01 Jan 2012 21:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=MP+X/2fmxRun5Ah6at5vOQauF3rj3dvfUiXdb1+4zQM=; b=UP5c1Dg1b1EC66Di3Tme2Ohufn3un7EbYmRvz/LBlhzzjxMwxMRrRxw/kLjHdXC6y2 JGWXvZSfw/7MbSzWoWNTh/l6ksQq2TBW2v8iKrFLac3gnNbMQ4/CZ04xn+MBxjVqLkxH 8GBi3m6If1cPKkB4chsHeC++TubUzFbneQ7ys= Received: by 10.182.117.8 with SMTP id ka8mr5322362obb.73.1325481578219; Sun, 01 Jan 2012 21:19:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.133.38 with HTTP; Sun, 1 Jan 2012 21:19:17 -0800 (PST) In-Reply-To: <20111230122109.GG1740@stefanha-thinkpad.localdomain> References: <20111230122109.GG1740@stefanha-thinkpad.localdomain> From: Ying-Shiuan Pan Date: Mon, 2 Jan 2012 13:19:17 +0800 Message-ID: To: qemu-devel@nongnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.214.173 Cc: Stefan Hajnoczi , peter.maydell@linaro.org Subject: Re: [Qemu-devel] virtio-net with virtio-mmio X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Hi, Stefan Thanks for your response. 2011/12/30 Stefan Hajnoczi > > On Wed, Dec 28, 2011 at 06:16:42PM +0800, Ying-Shiuan Pan wrote: > > I'm very interested in virtio-mmio Peter Maydell did for QEMU, > > (http://lists.nongnu.org/archive/html/qemu-devel/2011-11/msg01870.html) > > > > actually, I've tested the virtio-blk, and it is working. > > I applied those patch to QEMU-1.0 and brought the virtio_mmio.c from > > Linux-3.2-rc back to Linux-linaro-2.6.38. > > > > I also found a small bug in virito-mmio.c: virtio_mmio_write(), > > Peter forgot to break in each case of switch block. > > After fixed the small bug, the virtio-balloon works as well. > > PMM: Do you have a git branch where you could apply Ying-Shiuan's fix? hmm... I've sent Peter my patch :) > > > Then, when I attempted to enable the virtio-net, the initialization part is > > fine, > > however, the QEMU crashed and printed this message: > > "virtio-net header not in first element" > > > > It happens when the front-end virtio-net is invoking virtqueue_kick() at > > the end of try_fill_recv(). > > Then, QEMU gets this message and invokes virtio_net_receive(), then the > > error happens. > > virtio-net is looking at a virtqueue element (a packet buffer provided > by the guest OS into which QEMU will copy the received packet) but the > virtqueue element does not have the expected format.  You can check the > virtio specification for the details on the virtio-net buffer layout: > http://ozlabs.org/~rusty/virtio-spec/ > > It sounds like the vring is corrupted or QEMU's virtio code is not > correctly reading the virtqueue element (which is basically an iovec > array). > > virtio-net is more advanced than virtio-blk in how it uses virtio so > it's not surprising that you've discovered an issue.  Debugging this > comes down to looking at the vring descriptors and the virtqueue > elements that QEMU extracts. > > It sounds like there's a problem with the rx queue, you could try > indirect_desc=off to disable indirect vring descriptors to see if that > is part of the problem. > > Stefan I guessed that the problem was in adding header, virtio-net should insert its header to the ring buffer before its packet, correct me if I'm wrong. virtio-net driver (backend part) can use add_recvbuf_small() / add_recvbuf_big() / add_recvbuf_mergeable() depending on what features the virtio-net device (QEMU part) provides. I found that both small and big add the header, while the mergeable one does not. Besides, in that add_recvbuf_big(), the comments mentioned about a QEMU bug?? Anyway, I found a workaround solution, that is disable the VIRTIO_NET_F_MRG_RXBUF feature and make virtio-net driver use add_recvbuf_big() However, I am still not clear about how the problem happened. If I luckily figure out, I'll post it. :) So~ currently, virito-balloon, virtio-blk, and virtio-net can work properly with virtio-mmio. :D The following is the *workaround solution* which is for virtio-net driver part (frontend). ---- Best Regards, Ying-Shiuan Pan diff --git a/virtio_net.c b/virtio_net.c index 82dba5a..811e2d9 100644 --- a/virtio_net.c +++ b/virtio_net.c @@ -955,8 +955,10 @@ static int virtnet_probe(struct virtio_device *vdev) virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN)) vi->big_packets = true; +#ifndef ARM if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF)) vi->mergeable_rx_bufs = true; +#endif /* We expect two virtqueues, receive then send, * and optionally control. */