From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhlY2-0003wc-E0 for qemu-devel@nongnu.org; Mon, 02 Jan 2012 12:19:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RhlY0-0004Jo-Vl for qemu-devel@nongnu.org; Mon, 02 Jan 2012 12:19:46 -0500 Received: from mail-wi0-f173.google.com ([209.85.212.173]:44097) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RhlY0-0004Jg-OZ for qemu-devel@nongnu.org; Mon, 02 Jan 2012 12:19:44 -0500 Received: by wibhm2 with SMTP id hm2so9793195wib.4 for ; Mon, 02 Jan 2012 09:19:43 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20111230122109.GG1740@stefanha-thinkpad.localdomain> Date: Mon, 2 Jan 2012 17:19:42 +0000 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] virtio-net with virtio-mmio List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ying-Shiuan Pan Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org On Mon, Jan 2, 2012 at 5:19 AM, Ying-Shiuan Pan wrote: > 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 pa= rt 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 th= e >> > 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. =A0You can check th= e >> 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. =A0Debugging 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=3Doff 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 b= ug?? > > 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. Can you confirm which "virtio-net header not in first element" error is occurring? There are two instances in qemu/hw/virtio-net.c: virtio_net_receive() and virtio_net_flush_tx(). If you are really seeing the error from virtio_net_receive() then feature negotiation is broken. The guest will advertise mergeable receive buffers and the host (QEMU) should detect this in virtio_net_set_features(). This causes QEMU to set VirtIONet->mergeable_rx_bufs to true. If VirtIONet->mergeable_rx_bufs is true then the error you are seeing in virtio_net_receive() cannot happen: if (!n->mergeable_rx_bufs && elem.in_sg[0].iov_len !=3D guest_hdr_len) = { error_report("virtio-net header not in first element"); exit(1); } The only explanation is that the guest and host did not negotiate the mergeable receive buffers feature properly. That could mean Peter's QEMU patches are not calling invoking virtio_net_set_features() at the appropriate time or something else is broken - probably a virtio-mmio issue. AFAIK mergeable receive buffers are used by default and work correctly under virtio-pci. If you can debug this a little more we'll figure out what the problem is. Stefan