From owner-freebsd-virtualization@freebsd.org Mon Nov 18 09:06:14 2019 Return-Path: Delivered-To: freebsd-virtualization@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 768C91B9F3E for ; Mon, 18 Nov 2019 09:06:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47Gjjy2C5qz3Fhf for ; Mon, 18 Nov 2019 09:06:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 4B6A31B9F3D; Mon, 18 Nov 2019 09:06:14 +0000 (UTC) Delivered-To: virtualization@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 4B1791B9F3C for ; Mon, 18 Nov 2019 09:06:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Gjjy0YdYz3FhQ for ; Mon, 18 Nov 2019 09:06:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B03FB27AE8 for ; Mon, 18 Nov 2019 09:06:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xAI96DTl013101 for ; Mon, 18 Nov 2019 09:06:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xAI96DqY013091 for virtualization@FreeBSD.org; Mon, 18 Nov 2019 09:06:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 242023] bhyve pci_vtnet_rx broken after r354552 Date: Mon, 18 Nov 2019 09:06:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: aleksandr.fedorov@itglobal.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 09:06:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242023 --- Comment #9 from Aleksandr Fedorov --- Negotiated futures looks fine for me. VIRTIO_NET_F_MRG_RXBUF flag is zero. But I'm worried about how we use sc->rx_merge flag. During initialization, we set it to 1: https://svnweb.freebsd.org/base/head/usr.sbin/bhyve/pci_virtio_net.c?revisi= on=3D354552&view=3Dmarkup#l515 Than on features negotiation, we set it to 0: https://svnweb.freebsd.org/base/head/usr.sbin/bhyve/pci_virtio_net.c?revisi= on=3D354552&view=3Dmarkup#l575 But during the reset, we set it to 1: https://svnweb.freebsd.org/base/head/usr.sbin/bhyve/pci_virtio_net.c?revisi= on=3D354552&view=3Dmarkup#l161 And it seems that there is a race between pci_vtnet_rx() and pci_vtnet_rese= t(). If pci_vtnet_rx() is called after pci_vtnet_reset() immediately, than the w= rong code path is called (RX MRG BUF enabled). I have not yet installed windows to test this hypothesis, but using FreyBSD= as a guest system I discovered another problem. Start vm: sh vmrun.sh -c 2 -m 4096M -t tap1001 -d freebsd-12-0.img freebsd-0 Configure tap1001: ifconfig tap1001 192.168.1.5/24 up Ping VM: ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=3D0 ttl=3D64 time=3D0.544 ms Inside VM put vtnet0 interface down. root@vm0:~ # ifconfig vtnet0 down pci_vtnet_rx pci_vtnet_reset pci_vtnet_rx <<-- pci_vtnet_neg_features() is not called before RX. vtnet: ndesc (1040) out of range, driver confused? Assertion failed: (n >=3D 1 && cur_iov_len + n <=3D VTNET_MAXSEGS), function pci_vtnet_rx, file /afedorov/freebsd-head-clean/usr.sbin/bhyve/pci_virtio_net.c, line 239. Abort trap --=20 You are receiving this mail because: You are on the CC list for the bug.=