From owner-freebsd-virtualization@freebsd.org Wed Feb 10 18:09:00 2021 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 0012D54E788 for ; Wed, 10 Feb 2021 18:08:59 +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 4DbSSW60szz4rQk for ; Wed, 10 Feb 2021 18:08:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id CD35254E71A; Wed, 10 Feb 2021 18:08:59 +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 CA79854E719 for ; Wed, 10 Feb 2021 18:08:59 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DbSSW40dCz4rMv for ; Wed, 10 Feb 2021 18:08:59 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 67420223C2 for ; Wed, 10 Feb 2021 18:08:59 +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 11AI8xtP050711 for ; Wed, 10 Feb 2021 18:08:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11AI8xo0050710 for virtualization@FreeBSD.org; Wed, 10 Feb 2021 18:08:59 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 237441] Virtio net consistently truncates last byte of a fetch xfer with > 8956 bytes of payload Date: Wed, 10 Feb 2021 18:08:57 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: adam.chappell@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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.34 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, 10 Feb 2021 18:09:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237441 Adam Chappell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adam.chappell@gmail.com --- Comment #9 from Adam Chappell --- Would be intrigued to understand what the FreeBSD fix was here. Doesn't see= m to be in release notes. I believe this issue is not an issue with the FreeBSD guest but more likely an issue with the MacOS/Darwin poll() returning POLLP= RI events to Qemu's userland TCP stack, Slirp. When Slirp sees POLLPRI on a TCP stream it assumes (not unreasonably) that the incoming data has some urgent data in it. It makes some effort to craft a TCP segment=20 for the guest with URG flag and pointer set to a best guess. Unfortunately the guest VM's read() won't return urgent/OOB data in normal operation. As a result, data is omitted. >From my tests it seems very prevalent that MacOS poll() returns POLLPRI on = the last segment (perhaps it's signalling POLLPRI to tell the reader that the stream has finished?), which does explain why we lose the last byte or so. Lopping out the (revents & SLIRP_POLL_PRI) clause in slirp.c:slirp_pollfds_poll() in favour of the subsequent else-if makes things work, at the cost of NOPing out Slirp's likely hapless attempt= s to do URG reconstruction. RFC6093 seems to push us away from ever using TCP urgent in new apps, so ma= ybe that's not as bad as it seems. --=20 You are receiving this mail because: You are the assignee for the bug.=