On Wed, May 8, 2024 at 2:51 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > Designwise, a native VSOCK backend in QEMU really should implement the > same approach defined by firecracker, so that we have interoperability > with systemd, firecracker and cloud-hypervisor. See > > https://gitlab.com/qemu-project/qemu/-/issues/2095 > > https://github.com/firecracker-microvm/firecracker/blob/main/docs/vsock.md#firecracker-virtio-vsock-design > > This involves multiple UNIX sockets on the host > > 1 * /some/path - QEMU listens on this, and accepts connections > from other host processes. The client sends > "PORT <num>" to indicate that guest port it > is connecting to > > n * /some/path_$PORT - QEMU connect to this for outgoing connections > from the guest. Other host processes need > to listen on whatever path_$PORT need to be > serviced
The former is quite horrible, but okay. Out of curiosity, which clients are using that convention? > IOW, from a CLI pov, QEMU should need nothing more than > > -object vsock-forward,prefix=/some/path I would call this a "vsock-namespace" object with a matching namespace property on the virtio-vsock device. The id on the vsock-namespace object would also allow 1) adding vsock-forward objects hanging from the namespace 2) omitting the prefix to only allow specifying connections via vsock-forward. I agree that allowing interoperability with existing implementations is nice to have, at least as a principle. Paolo
