From owner-freebsd-virtualization@freebsd.org Wed Jul 31 15:50:25 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 DC4DDA215D for ; Wed, 31 Jul 2019 15:50:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 45zHv54Bgyz3ysm for ; Wed, 31 Jul 2019 15:50:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8E179A215C; Wed, 31 Jul 2019 15:50:25 +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 8DD40A215B for ; Wed, 31 Jul 2019 15:50:25 +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 45zHv51Wczz3ysh for ; Wed, 31 Jul 2019 15:50:25 +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 039473DB3 for ; Wed, 31 Jul 2019 15:50:25 +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 x6VFoO5d080258 for ; Wed, 31 Jul 2019 15:50:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6VFoOAL080257 for virtualization@FreeBSD.org; Wed, 31 Jul 2019 15:50:24 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 239118] in ESXi: Panic in ether_output_frame Date: Wed, 31 Jul 2019 15:50:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: iflib, panic X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkelsey@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@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-Rspamd-Queue-Id: 45zHv54Bgyz3ysm X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.17 / 15.00]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.17)[-0.165,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: Wed, 31 Jul 2019 15:50:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239118 --- Comment #9 from Patrick Kelsey --- (In reply to Marius Strobl from comment #7) > I'd say that with an INTx-type interrupt or a single MSI vector, i. e. all > the "legacy" interrupt support iflib is about, there's just no other way > than to operate in combined RXTX mode (as opposed to multiple MSI-X vecto= rs > which can be associated to either RX or TX on a per-vector basis). > Thus, - as actually already written in my private e-mail to pkelsey@ and = the > submitter on June 25th - I fully agree with markj@ analysis that > vmxnet3_isc_txd_credits_update() currently isn't reentrant as well as with > his fix (I'd probably code it to be more in line with the index updating = in > vmxnet3_isc_rxd_available(), though). > However, as I also already wrote in said e-mail, on top of that it isn't > obvious to me that it's safe to update txc->vxcr_next and txc->vxcr_gen > non-atomically/lockless since r343291 dropped the locking around these > operations. Marius, you are missing the point, which is that you have failed to consider the case of drivers that don't use TX interrupts at all, of which the vmx driver is an example. Drivers that don't use TX interrupts still only have= one queue-related interrupt in legacy mode. By assuming that all drivers want to (i.e., are designed to) do TX processi= ng during their RX interrupts, even when those drivers have clearly indicated = they are not implementing TX mode or RXTX mode hardware interrupts in their interface to iflib, you are breaking drivers such as vmx. I fully agree that vmxnet3_isc_txd_credits_update() is not re-entrant - bec= ause it was explicitly designed on the basis that it does not have to be. Anyon= e of course is welcome to redesign the vmx driver under changed design assumptio= ns, and I would caution anyone going down that path that the whole vmx driver should be re-examined in this case. I think it would be better to fix the iflib legacy mode interrupt setup so = it does not assume it can invoke TX processing from the RX interrupt unless the driver has indicated it is using TXRX mode, or perhaps indicated that it is using hardware-based TX interrupts. --=20 You are receiving this mail because: You are the assignee for the bug.=