From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9adR-0004CT-CM for qemu-devel@nongnu.org; Mon, 29 Jun 2015 11:06:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9adN-0007Wd-66 for qemu-devel@nongnu.org; Mon, 29 Jun 2015 11:06:13 -0400 Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:38197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9adM-0007VA-U2 for qemu-devel@nongnu.org; Mon, 29 Jun 2015 11:06:09 -0400 Received: by wibdq8 with SMTP id dq8so75116825wib.1 for ; Mon, 29 Jun 2015 08:06:08 -0700 (PDT) Date: Mon, 29 Jun 2015 16:06:04 +0100 From: Stefan Hajnoczi Message-ID: <20150629150604.GL32151@stefanha-thinkpad.redhat.com> References: <55898005.2040600@moose.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m0XfRaZG5aslkcJX" Content-Disposition: inline In-Reply-To: <55898005.2040600@moose.net> Subject: Re: [Qemu-devel] vmxnet3, vnet_hdr, and minimum length padding List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Brian Kress Cc: qemu-devel@nongnu.org --m0XfRaZG5aslkcJX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 23, 2015 at 11:49:25AM -0400, Brian Kress wrote: > When running ESXi under qemu there is an issue with the ESXi guest > discarding packets that are too short. The guest discards any packets un= der > the normal minimum length for an ethernet packet (60). This results in o= dd > behaviour where other hosts or VMs on other hosts can communicate with the > ESXi guest just fine (since there's a physical NIC somewhere doing paddin= g), > but VMs on the host and the host itself cannot because the ARP request > packets are too small for the ESXi host to accept. > Someone in the past thought this was worth fixing, and added code to = the > vmxnet3 qemu emulation such that if it is receiving packets smaller than = 60 > bytes to pad the packet out to 60. Unfortunately this code is wrong (or at > least in the wrong place). It does so BEFORE before taking into account t= he > vnet_hdr at the front of the packet added by the tap device. As a resul= t, > it might add padding, but it never adds enough. Specifically it adds 10 > less (the length of the vnet_hdr) than it needs to. > The following (hopefully "obviously correct") patch simply swaps the > order of processing the vnet header and the padding. With this patch an > ESXi guest is able to communicate with the host or other local VMs. >=20 >=20 > --- a/qemu-2.3.0/hw/net/vmxnet3.c 2015-04-27 10:08:24.000000000 -04= 00 > +++ b/qemu-2.3.0/hw/net/vmxnet3.c 2015-06-23 11:38:48.865728713 -04= 00 > @@ -1879,6 +1879,12 @@ > return -1; > } >=20 > + if (s->peer_has_vhdr) { > + vmxnet_rx_pkt_set_vhdr(s->rx_pkt, (struct virtio_net_hdr *)buf); > + buf +=3D sizeof(struct virtio_net_hdr); > + size -=3D sizeof(struct virtio_net_hdr); > + } > + > /* Pad to minimum Ethernet frame length */ > if (size < sizeof(min_buf)) { > memcpy(min_buf, buf, size); > @@ -1887,12 +1893,6 @@ > size =3D sizeof(min_buf); > } >=20 > - if (s->peer_has_vhdr) { > - vmxnet_rx_pkt_set_vhdr(s->rx_pkt, (struct virtio_net_hdr *)buf); > - buf +=3D sizeof(struct virtio_net_hdr); > - size -=3D sizeof(struct virtio_net_hdr); > - } > - > vmxnet_rx_pkt_set_packet_type(s->rx_pkt, > get_eth_packet_type(PKT_GET_ETH_HDR(buf))); Thanks, applied to my net tree: https://github.com/stefanha/qemu/commits/net Stefan --m0XfRaZG5aslkcJX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVkV7cAAoJEJykq7OBq3PIfbUH/0iwvAxHCuvsIKGVE6lz7sNH xSA8lR1/8HGjimdpayWGYssESVzlYrh+XW4DVLD1TR2OVyZguaVM3Z710J57uKV4 2bS+p0w59IB3J8q7hpm3uKg3XYM9mkSoiaM9L/WDAUXZY9qWZiapM8WT9paQftIr li94z16RfHd3sBOOvtF007Bh26tBm5uqm1x3Rg2HYO8J4g1QEGUmNJoObSBl3T4M XCwdYV2z5SOtHmpxhBL1NQkLN4fR/7G/KDYf0P37Teq4tioUu21osoiKtqMUewTY z4XrWTygHBabv8VI8ATuq01Qdt1YEYJCXJavOCfNvV1JXFlCM1U5Oe9jkHSPMSk= =f3yM -----END PGP SIGNATURE----- --m0XfRaZG5aslkcJX--