From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3WL3-0003OE-JT for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:50:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3WKy-0003LX-Nz for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:50:56 -0400 Received: from [199.232.76.173] (port=56374 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3WKy-0003LT-FR for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:50:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9976) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3WKx-0000nT-As for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:50:52 -0400 Subject: Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network From: Mark McLoughlin In-Reply-To: <4AE9A90F.1060108@codemonkey.ws> References: <1256807803.10825.39.camel@blaa> <1256815818-sup-7805@xpc65.scottt> <1256818566.10825.58.camel@blaa> <4AE9A299.5060003@codemonkey.ws> <1256826351.10825.69.camel@blaa> <4AE9A90F.1060108@codemonkey.ws> Content-Type: text/plain Date: Thu, 29 Oct 2009 14:48:39 +0000 Message-Id: <1256827719.10825.75.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Rusty Russell , Scott Tsai , qemu-devel , kvm , Dustin Kirkland On Thu, 2009-10-29 at 09:39 -0500, Anthony Liguori wrote: > Mark McLoughlin wrote: > > On Thu, 2009-10-29 at 09:11 -0500, Anthony Liguori wrote: > > > >> Mark McLoughlin wrote: > >> > >>>> tap_set_offload(csum: 1, tso4: 1, tso6: 1, ecn: 1) > >>>> being called and get an mtu of 1500 on virbr0 using his birdge.sh script. > >>>> > >>>> virtio_net_receive2 was trying to transfer a 1534 byte packet (1524 'size' + 10 'virtio_net_hdr') > >>>> and the guest only had 1524 bytes of space in its input descriptors. > >>>> > >>>> > >>> Okay, that sounds like a bug in Dustin's version of the guest virtio-net > >>> driver - if it is only supplying 1524 byte buffers, it should not be > >>> saying it supports the VIRTIO_NET_F_GUEST_TSO4 feature > >>> > >>> > >> See: > >> > >> commit 8eca6b1bc770982595db2f7207c65051572436cb > >> Author: aliguori > >> Date: Sun Apr 5 17:40:08 2009 +0000 > >> > >> Fix oops on 2.6.25 guest (Rusty Russell) > >> > >> I believe this is behind the following: > >> https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128 > >> > >> virtio_pci in 2.6.25 didn't do feature negotiation correctly: it > >> acked every > >> bit. Fortunately, we can detect this. > >> > >> Signed-off-by: Rusty Russell > >> Signed-off-by: Anthony Liguori > >> > >> It looks like Rusty's fix wasn't enough. If I change virtio-net to only > >> advertise F_MAC, we don't run into this problem. > >> > > > > If it's not acking VBAD_FEATURE, then it doesn't sound like the same > > issue > > > > It was acking VBAD_FEATURE when I tested it. > > But if you look at the patch, it whitelists the following features: > > features |= (1 << VIRTIO_NET_F_MAC); > features |= (1 << VIRTIO_NET_F_GUEST_CSUM); > features |= (1 << VIRTIO_NET_F_GUEST_TSO4); > features |= (1 << VIRTIO_NET_F_GUEST_TSO6); > features |= (1 << VIRTIO_NET_F_GUEST_ECN); Ah, it all makes sense now. I was getting confused between HOST_* and GUEST_* this should have been: features |= (1 << VIRTIO_NET_F_MAC); features |= (1 << VIRTIO_NET_F_HOST_CSUM); features |= (1 << VIRTIO_NET_F_HOST_TSO4); features |= (1 << VIRTIO_NET_F_HOST_TSO6); features |= (1 << VIRTIO_NET_F_HOST_ECN); Could you try that Dustin? > Which is why it's ack'ing TSO4. Removing TSO4 didn't seem to fix it > for me. Odd. Cheers, Mark.