[Bug 237441] Virtio net consistently truncates last byte of a fetch xfer with > 8956 bytes of payload

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237441

Adam Chappell <adam.chappell at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adam.chappell at gmail.com

--- Comment #9 from Adam Chappell <adam.chappell at gmail.com> ---
Would be intrigued to understand what the FreeBSD fix was here. Doesn't seem 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 POLLPRI
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 
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 attempts to
do URG reconstruction.

RFC6093 seems to push us away from ever using TCP urgent in new apps, so maybe
that's not as bad as it seems.

-- 
You are receiving this mail because:
You are on the CC list for the bug.