bhyve: Implement the libslirp notify callback

libslirp can invoke a callback when received data is removed from a
socket buffer, generally because the guest ACKed some data. Previously
it didn't do

bhyve: Implement the libslirp notify callback

libslirp can invoke a callback when received data is removed from a
socket buffer, generally because the guest ACKed some data. Previously
it didn't do anything, but it needs to wake up the poll thread to get
reasonable throughput.

Suppose one is using scp to copy data into a guest filesystem via the
slirp backend. Data is received on libslirp's socket, which we poll for
data in slirp_pollfd_td_loop(). That data gets buffered in priv->pipe,
and eventually is placed in the device model's RX rings by the backend's
mevent handler. When implementing TCP, libslirp holds on to a copy of
data until it's ACKed by the guest via slirp_send(), at which point it
drops that data and invokes the notify callback.

The initial implementation of this backend didn't take into account the
fact that slirp_pollfds_fill() will not add libslirp's socket to the
pollfd set if more than a threshold amount of data is already buffered.
Then poll() needs to time out before the backend sends more data to the
guest. With a default timeout of 500ms, this kills throughput.

Use a pipe to implement a simple in-band signal to the poll thread so
that it reacts quickly when more buffer space becomes available.

MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D48192

show more ...

bhyve: Use a non-blocking read in slirp_recv()

When using the slirp backend with the e1000 frontend, I otherwise get
hangs in readv(), caused by the e1000 emulation not checking whether
bytes are av

bhyve: Use a non-blocking read in slirp_recv()

When using the slirp backend with the e1000 frontend, I otherwise get
hangs in readv(), caused by the e1000 emulation not checking whether
bytes are available before trying to read them. In particular, that
device model expects the recv callback to return 0 if no bytes are
available, and with slirp it would end up blocking forever. The virtio
device model uses the peek_recvlen to check first, so I didn't notice
the problem when implementing the slirp backend.

Make the slirp backend more flexible to accommodate e1000.

MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D48164

show more ...

bhyve: correct slirp_recv_disable()

Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D43472

bhyve: Fix a leak that happens when we fail to load a hostfwd rule

Reported by: Coverity
Fixes: c5359e2af5ab ("bhyve: Add a slirp network backend")

bhyve: Add a slirp network backend

This enables a subset of the functionality provided by QEMU's user
networking implementation. In particular, it uses net/libslirp, the
same library as QEMU.

libs

bhyve: Add a slirp network backend

This enables a subset of the functionality provided by QEMU's user
networking implementation. In particular, it uses net/libslirp, the
same library as QEMU.

libslirp is permissively licensed but has some dependencies which make
it impractical to bring into the base system (glib in particular). I
thus opted to make bhyve dlopen the libslirp.so, which can be installed
via pkg. The library header is imported into bhyve.

The slirp backend takes a "hostfwd" which is identical to QEMU's
hostfwd. When configured, bhyve opens a host socket and listens for
connections, which get forwarded to the guest. For instance,
"hostfwd=tcp::1234-:22" allows one to ssh into the guest by ssh'ing to
port 1234 on the host, e.g., via 127.0.0.1. I didn't try to hook up
guestfwd support since I don't personally have a use-case for it yet,
and I think it won't interact nicely with the capsicum sandbox.

Reviewed by: jhb
Tested by: rew
MFC after: 1 month
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D42510

show more ...