We observed slow responses on a host forwarded port on Windows. Investigation revealed that qemu_fd_register was being called with fd=-1 and this caused g_poll in qemu_poll_ns timing out. I tracked this behavior to following commit: 748f8f4 slirp: replace qemu_set_nonblock()
@@ -482,7 +483,8 @@ void tcp_connect(struct socket *inso) tcp_close(sototcpcb(so)); /* This will sofree() as well */ return; } - qemu_set_nonblock(s); + slirp_set_nonblock(s); + so->slirp->cb->register_poll_fd(so->s); It seems that calling register_poll_fd with so->s instead of s may be a typo. Changing it back to s solves this issue. The commit 748f8f4 made similar change in tcp_fconnect but I have not touched it. Signed-off-by: Hafiz Abid Qadeer <ab...@codesourcery.com> --- src/tcp_subr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tcp_subr.c b/src/tcp_subr.c index a1016d9..1b6d602 100644 --- a/src/tcp_subr.c +++ b/src/tcp_subr.c @@ -493,7 +493,7 @@ void tcp_connect(struct socket *inso) return; } slirp_set_nonblock(s); - so->slirp->cb->register_poll_fd(so->s, so->slirp->opaque); + so->slirp->cb->register_poll_fd(s, so->slirp->opaque); slirp_socket_set_fast_reuse(s); opt = 1; setsockopt(s, SOL_SOCKET, SO_OOBINLINE, &opt, sizeof(int)); -- 2.25.1