On 14 Jun 2020, at 20:51, Tom Jones <t...@freebsd.org> wrote:
> On Mon, Jun 08, 2020 at 09:51:36PM +0000, Jessica Clarke wrote:
>> Author: jrtc27
>> Date: Mon Jun 8 21:51:36 2020
>> New Revision: 361944
>> URL: https://svnweb.freebsd.org/changeset/base/361944
>>
>> Log:
>> virtio: Support non-legacy network device and queue
>>
>> The non-legacy interface always defines num_buffers in the header,
>> regardless of whether VIRTIO_NET_F_MRG_RXBUF, just leaving it unused. We
>> also need to ensure our virtqueue doesn't filter out VIRTIO_F_VERSION_1
>> during negotiation, as it supports non-legacy transports just fine. This
>> fixes network packet transmission on TinyEMU.
>>
>> Reviewed by: br, brooks (mentor), jhb (mentor)
>> Approved by: br, brooks (mentor), jhb (mentor)
>> Differential Revision: https://reviews.freebsd.org/D25132
>>
>> Modified:
>> head/sys/dev/virtio/network/if_vtnet.c
>> head/sys/dev/virtio/network/if_vtnetvar.h
>> head/sys/dev/virtio/virtio.c
>> head/sys/dev/virtio/virtqueue.c
>>
>
> Hi Jessica,
>
> After updating my current bhyve vm today (on a 12.1 host), networking no
> longer
> works. Reverting this commit seems to resolve the issue. I think vtnet is not
> passing enough data up to the ip layer.
>
> If I capture on the tap interface for the vm I see arp requests and arp
> replies, however kern.msgbuf is full of:
>
> <5>arp: short packet received on vtnet0
>
> and netstat does not see any replies to arp requests:
>
> root@freebsd-current:~ # netstat -s -p arp
> arp:
> 11 ARP requests sent
> 0 ARP requests failed to sent
> 0 ARP replies sent
> 0 ARP requests received
> 0 ARP replies received
> 0 ARP packets received
> 24 total packets dropped due to no ARP entry
> 2 ARP entrys timed out
> 0 Duplicate IPs seen
>
> If I set up an arp entry manually I can see ICMP echo requests and responses
> on
> the tap interface, but the vm does not see the responses.
>
> root@freebsd-current:~ # netstat -s -p ip
> ip:
> 7 total packets received
> 0 bad header checksums
> 0 with size smaller than minimum
> 7 with data size < data length
> 0 with ip length > max ip packet size
> 0 with header length < data size
> 0 with data length < header length
>
> The line
>
> 7 with data size < data length
>
> makes me think that vtnet is truncating packets.
>
> markj pointed me at this bug in irc which might also be related:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247242
Hi Tom,
Sorry about that; it seems bhyve hits the "legacy and no MrgRxBuf"
case. Could you please try the patch below?
Jess
diff --git a/sys/dev/virtio/network/if_vtnet.c
b/sys/dev/virtio/network/if_vtnet.c
index 7a0859cc0eb1..7e10b75f7f66 100644
--- a/sys/dev/virtio/network/if_vtnet.c
+++ b/sys/dev/virtio/network/if_vtnet.c
@@ -1819,9 +1819,10 @@ vtnet_rxq_eof(struct vtnet_rxq *rxq)
adjsz = sizeof(struct vtnet_rx_header);
/*
* Account for our pad inserted between the header
- * and the actual start of the frame.
+ * and the actual start of the frame. This includes
+ * the unused num_buffers when using a legacy device.
*/
- len += VTNET_RX_HEADER_PAD;
+ len += adjsz - sc->vtnet_hdr_size;
} else {
mhdr = mtod(m, struct virtio_net_hdr_mrg_rxbuf *);
nbufs = mhdr->num_buffers;
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
