From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dustin Kirkland Subject: Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network Date: Thu, 29 Oct 2009 09:39:56 -0500 Message-ID: <1256827196.25064.118.camel@x200> References: <1256807803.10825.39.camel@blaa> <1256815818-sup-7805@xpc65.scottt> Reply-To: kirkland@canonical.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DD8gxWg4LyZdwr4PtjTz" Cc: Mark McLoughlin , qemu-devel , kvm , Anthony Liguori To: Scott Tsai Return-path: Received: from adelie.canonical.com ([91.189.90.139]:42403 "EHLO adelie.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753809AbZJ2OkE (ORCPT ); Thu, 29 Oct 2009 10:40:04 -0400 In-Reply-To: <1256815818-sup-7805@xpc65.scottt> Sender: kvm-owner@vger.kernel.org List-ID: --=-DD8gxWg4LyZdwr4PtjTz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote: > Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009= : > > Assuming this is something like the virtio-net in 2.6.26, there was no > > receivable buffers support so (as Scott points out) it must be that > > we've read a packet from the tap device which is >1514 bytes (or >1524 > > bytes with IFF_VNET_HDR) but the guest has not supplied buffers which > > are large enough to take it >=20 > > One thing to check is that the tap device is being initialized by > > qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO > > should not be enabled, because the guest cannot handle large GSO packet= s >=20 > > Another possibility is that the MTU on the bridge in the host is too > > large and that's what's causing the large packets to be sent >=20 > Using Dustin's image, I see: > virtio_net_set_features(features: 0x00000930) > 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. >=20 > 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. >=20 > BTW, I can also reproduce this running Dustin's image inside Fedora 11's = qemu-0.10.6-9.fc11.x86_64. >=20 > The patch I posted earlier actually only applies to the 0.10 branch, here= 's a patch that compiles for 0.11: Hi Scott, Thanks for this. Testing this, kvm doesn't crash. And the guest has working network connectivity, until I saturate the network connection with nc. At that point, the guest loses network connectivity all together. So the fix is not quite ideal, yet. :-Dustin --=-DD8gxWg4LyZdwr4PtjTz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrpqTwACgkQs7pNXIOmEZTbKgCgrS/s3Utw1qrD+fJNyBZYgeTU HjUAn2HeKv9YDx2ZoCeD0Wt7oXcPuI3n =+Nyd -----END PGP SIGNATURE----- --=-DD8gxWg4LyZdwr4PtjTz-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3WAZ-0007gK-Tx for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:40:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3WAY-0007fX-HL for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:40:07 -0400 Received: from [199.232.76.173] (port=44055 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3WAY-0007fG-1b for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:40:06 -0400 Received: from adelie.canonical.com ([91.189.90.139]:48939) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3WAW-00077R-NV for qemu-devel@nongnu.org; Thu, 29 Oct 2009 10:40:05 -0400 Subject: Re: [Qemu-devel] qemu-kvm-0.11 regression, crashes on older guests with virtio network From: Dustin Kirkland In-Reply-To: <1256815818-sup-7805@xpc65.scottt> References: <1256807803.10825.39.camel@blaa> <1256815818-sup-7805@xpc65.scottt> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DD8gxWg4LyZdwr4PtjTz" Date: Thu, 29 Oct 2009 09:39:56 -0500 Message-ID: <1256827196.25064.118.camel@x200> Mime-Version: 1.0 Reply-To: kirkland@canonical.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Tsai Cc: Mark McLoughlin , qemu-devel , kvm --=-DD8gxWg4LyZdwr4PtjTz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2009-10-29 at 20:00 +0800, Scott Tsai wrote: > Excerpts from Mark McLoughlin's message of Thu Oct 29 17:16:43 +0800 2009= : > > Assuming this is something like the virtio-net in 2.6.26, there was no > > receivable buffers support so (as Scott points out) it must be that > > we've read a packet from the tap device which is >1514 bytes (or >1524 > > bytes with IFF_VNET_HDR) but the guest has not supplied buffers which > > are large enough to take it >=20 > > One thing to check is that the tap device is being initialized by > > qemu-kvm using TUNSETOFFLOAD with either zero or TUN_F_CSUM - i.e. GSO > > should not be enabled, because the guest cannot handle large GSO packet= s >=20 > > Another possibility is that the MTU on the bridge in the host is too > > large and that's what's causing the large packets to be sent >=20 > Using Dustin's image, I see: > virtio_net_set_features(features: 0x00000930) > 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. >=20 > 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. >=20 > BTW, I can also reproduce this running Dustin's image inside Fedora 11's = qemu-0.10.6-9.fc11.x86_64. >=20 > The patch I posted earlier actually only applies to the 0.10 branch, here= 's a patch that compiles for 0.11: Hi Scott, Thanks for this. Testing this, kvm doesn't crash. And the guest has working network connectivity, until I saturate the network connection with nc. At that point, the guest loses network connectivity all together. So the fix is not quite ideal, yet. :-Dustin --=-DD8gxWg4LyZdwr4PtjTz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrpqTwACgkQs7pNXIOmEZTbKgCgrS/s3Utw1qrD+fJNyBZYgeTU HjUAn2HeKv9YDx2ZoCeD0Wt7oXcPuI3n =+Nyd -----END PGP SIGNATURE----- --=-DD8gxWg4LyZdwr4PtjTz--