Speaker
Description
Several userspace VMMs emulate virtio-vsock devices entirely in userspace, and vhost-user-vsock provides a similar capability through the vhost-user protocol, to reduce the kernel attack surface or to run on platforms where vhost-vsock is not available. However, only the vhost-vsock kernel module, which emulates the virtio-vsock device in the host kernel, integrates directly with AF_VSOCK, so these backends expose Unix domain sockets to host applications, following the hybrid-vsock model introduced by Firecracker.
In the hybrid-vsock model, to connect to a guest, a host application opens a Unix socket and sends a text command like "CONNECT <port>\n". To receive connections from a guest, it listens on a separate Unix socket named /path/to/uds_<port>. This works, but it requires every host application to implement this ad-hoc protocol instead of using standard AF_VSOCK sockets, and the guest CID is not visible to the host kernel at all.
This talk explores a kernel interface that would let any process emulating a vsock device in userspace, such as the VMM itself or a vhost-user backend, register a guest CID and use AF_VSOCK sockets instead of Unix sockets, keeping the same one-socket-per-connection model that hybrid-vsock already uses. One possible approach is to introduce a new protocol type for AF_VSOCK (or a socket option) that allows a process to claim a CID through bind() and inject guest connections into the host's AF_VSOCK stack through the standard accept() and connect() calls, while the device emulation remains entirely in userspace. Host services would then reach these guests with a simple connect(AF_VSOCK, guest_cid, port), exactly as they do with kernel vhost-vsock, and VMMs would need minimal changes to switch from AF_UNIX to AF_VSOCK. Because this interface operates at the AF_VSOCK level, it is not tied to virtio and could serve any existing or future vsock transport.
Topics for discussion include: the right kernel API design, whether there are existing interfaces to follow or reuse, and how it should interact with network namespaces recently supported by AF_VSOCK.