https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237441
Adam Chappell <adam.chapp...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adam.chapp...@gmail.com
--- Comment #9 from Adam Chappell <adam.chapp...@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 the assignee for the bug.
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
