From owner-svn-src-head@freebsd.org Mon Jun 15 19:32:20 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F29C03415B3; Mon, 15 Jun 2020 19:32:20 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49m1gS67XKz4f3l; Mon, 15 Jun 2020 19:32:20 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: vmaffione) by smtp.freebsd.org (Postfix) with ESMTPSA id CCED32A0B6; Mon, 15 Jun 2020 19:32:20 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id e16so13611840qtg.0; Mon, 15 Jun 2020 12:32:20 -0700 (PDT) X-Gm-Message-State: AOAM533igznWN2C6xB0VO6B+I2IHCAvMOP5dyPK1NlUH9sApAFElmFXa i4oY53Il3m8G94gLUg+pEdigs15MLDMs/OC5RLk= X-Google-Smtp-Source: ABdhPJzRziYRPd4gvcQls6kMtFuebquU144c4W+RD+zrDHExh93oZehD/ijWZoxwPHYNd7QgtFQZGbL/QiCk9qvR9fc= X-Received: by 2002:ac8:67d7:: with SMTP id r23mr18044180qtp.110.1592249540151; Mon, 15 Jun 2020 12:32:20 -0700 (PDT) MIME-Version: 1.0 References: <202006082151.058LpabU003001@repo.freebsd.org> <20200614195126.GB68578@tom-desk.erg.abdn.ac.uk> <97EEF019-16A4-4626-A484-A00979B52A74@freebsd.org> <20200614212230.GC68578@tom-desk.erg.abdn.ac.uk> <0FD9E443-1B40-4495-B2C0-4803121EF911@freebsd.org> In-Reply-To: <0FD9E443-1B40-4495-B2C0-4803121EF911@freebsd.org> From: Vincenzo Maffione Date: Mon, 15 Jun 2020 21:32:08 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r361944 - in head/sys/dev/virtio: . network To: Jessica Clarke Cc: Tom Jones , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 19:32:21 -0000 Il giorno lun 15 giu 2020 alle ore 00:05 Jessica Clarke ha scritto: > On 14 Jun 2020, at 22:22, Tom Jones wrote: > > On Sun, Jun 14, 2020 at 09:56:03PM +0100, Jessica Clarke wrote: > >> On 14 Jun 2020, at 20:51, Tom Jones 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 > >> > > > > This changed fixed the issue for me. Please feel free to add > > > > Tested By: thj > > > > when you commit. > > Great, thanks for the report. > > > In testing I this lor went by, I wonder if this is something you care > about: > > > > acquiring duplicate lock of same type: "vtnet0-rx0" > > 1st vtnet0-rx0 @ > /usr/home/tj/code/freebsd/projects/review-D25220/sys/dev/virtio/network/if_vtnet.c:1780 > > 2nd vtnet0-rx0 @ > /usr/home/tj/code/freebsd/projects/review-D25220/sys/kern/subr_taskqueue.c:281 > > stack backtrace: > > #0 0xffffffff80c32881 at witness_debugger+0x71 > > #1 0xffffffff80ba3e54 at __mtx_lock_flags+0x94 > > #2 0xffffffff80c24bd2 at taskqueue_enqueue+0x42 > > #3 0xffffffff80a1af99 at vtnet_rxq_tq_intr+0xb9 > > #4 0xffffffff80c2520a at taskqueue_run_locked+0xaa > > #5 0xffffffff80c26284 at taskqueue_thread_loop+0x94 > > #6 0xffffffff80b830e0 at fork_exit+0x80 > > #7 0xffffffff81040eae at fork_trampoline+0xe > > Hm, I think that's just a false-positive, because if_vtnet constructs > the taskqueue using the same name as its own internal mutexes. Though > the locking around vtnet_rx_vq_intr and vtnet_rxq_tq_intr is a bit > fishy given they're rather similar yet inconsistent. I would imagine > rxq->vtnrx_stats.vrxs_rescheduled is supposed to be protected by that > mutex, but wouldn't like to say whether taskqueue_enqueue needs to be. > Vincenzo, you recently touched code around there, perhaps you could be > persuaded to have a quick look?.. > Yes, you are right on both. There is also code duplication that can be easily removed. I will fix that. Cheers, Vincenzo > > Jess > >