Hi Robin, On Tue, Sep 22, 2020 at 10:46 PM Robin Meinzer <robmeinze...@gmx.de> wrote: > I added Stefano Garzarella and qemu-devel as you asked. I wonder if > you don't support SOCK_DGRAM but only SOCK_STREAM, why having code for > it then? There are functions like vsock_dgram_connect and a proto_ops > struct specifically for SOCK_DGRAM, but any attempt to create a socket > for it ends with -ENODEV (transport_dgram is NULL, I guess it's on > purpose because you don't support it as you said).
AF_VSOCK supports multiple transports. Some transports (e.g. vmci) implement SOCK_DGRAM, this is the reason for the code in the vsock core. virtio-vsock transport currently supports only SOCK_STREAM. Some people were implementing SOCK_SEQPACKET, but no upstream patches has been sent yet. > Another thing, could you please tell me what I have to set in the > kernel .config to have vsockets working out of the box, for now lsmod > doesn't show me vmw_vsock_transport_common or vsock or vsock_host > existence in the form of a autoloaded module at all. In the guest the vsock modules are loaded when the virtio-vsock device is discovered on the PCI bus. In the host the vhost-vsock module (and other vsock modules) is automatically loaded the first time that a process opens /dev/vhost-vsock. For testing in the host, you can use the vsock_loopback module that should be automatically loaded the first time that a process create an AF_VSOCK socket. Note: if other vsock modules (e.g. vhost-vsock) are already loaded, you must load vsock_loopback by hand. Stefano