When I use qemu's native vsock support and the guest connects to a socket on the host and then does a partial shutdown (SHUT_WR) of that socket, that information is visible from the host side: attempting to read() from the socket will return 0.
When using vhost-device-vsock, this doesn't happen. Looking at the code there is nowhere that calls shutdown() and no mention of SHUT_WR. Being able to read EOF from the reader side of a socket and then still reply on the writer side is an important part of many protocols.
In particular this makes it very difficult to implement systemd's vmm.notify_socket: the protocol there is:
- receive a connection
- read to EOF
- close the writer end from your side
but the "read to EOF" part will hang forever because both sides are still holding the socket open.
The relevant systemd code is here: https://github.com/systemd/systemd/blob/8685f8edd17a5e465bf05d733ac22c010c464938/src/libsystemd/sd-daemon/sd-daemon.c#L603
Note that they do SHUT_WR and then a read() to wait for the socket to be closed from the other side.
When I use qemu's native vsock support and the guest connects to a socket on the host and then does a partial shutdown (
SHUT_WR) of that socket, that information is visible from the host side: attempting to read() from the socket will return 0.When using vhost-device-vsock, this doesn't happen. Looking at the code there is nowhere that calls
shutdown()and no mention ofSHUT_WR. Being able to read EOF from the reader side of a socket and then still reply on the writer side is an important part of many protocols.In particular this makes it very difficult to implement systemd's vmm.notify_socket: the protocol there is:
but the "read to EOF" part will hang forever because both sides are still holding the socket open.
The relevant systemd code is here: https://github.com/systemd/systemd/blob/8685f8edd17a5e465bf05d733ac22c010c464938/src/libsystemd/sd-daemon/sd-daemon.c#L603
Note that they do
SHUT_WRand then a read() to wait for the socket to be closed from the other side.