Hi guys, I'm currently interested on implement a multi-transport support for VSOCK in order to handle nested VMs.
As Stefan suggested me, I started to look at this discussion: https://lkml.org/lkml/2017/8/17/551 Below I tried to summarize a proposal for a discussion, following the ideas from Dexuan, Jorgen, and Stefan. We can define two types of transport that we have to handle at the same time (e.g. in a nested VM we would have both types of transport running together): - 'host side transport', it runs in the host and it is used to communicate with the guests of a specific hypervisor (KVM, VMWare or HyperV) Should we support multiple 'host side transport' running at the same time? - 'guest side transport'. it runs in the guest and it is used to communicate with the host transport The main goal is to find a way to decide what transport use in these cases: 1. connect() / sendto() a. use the 'host side transport', if the destination is the guest (dest_cid > VMADDR_CID_HOST). If we want to support multiple 'host side transport' running at the same time, we should assign CIDs uniquely across all transports. In this way, a packet generated by the host side will get directed to the appropriate transport based on the CID b. use the 'guest side transport', if the destination is the host (dest_cid == VMADDR_CID_HOST) 2. listen() / recvfrom() a. use the 'host side transport', if the socket is bound to VMADDR_CID_HOST, or it is bound to VMADDR_CID_ANY and there is no guest transport. We could also define a new VMADDR_CID_LISTEN_FROM_GUEST in order to address this case. If we want to support multiple 'host side transport' running at the same time, we should find a way to allow an application to bound a specific host transport (e.g. adding new VMADDR_CID_LISTEN_FROM_KVM, VMADDR_CID_LISTEN_FROM_VMWARE, VMADDR_CID_LISTEN_FROM_HYPERV) b. use the 'guest side transport', if the socket is bound to local CID different from the VMADDR_CID_HOST (guest CID get with IOCTL_VM_SOCKETS_GET_LOCAL_CID), or it is bound to VMADDR_CID_ANY (to be backward compatible). Also in this case, we could define a new VMADDR_CID_LISTEN_FROM_HOST. Thanks in advance for your comments and suggestions. Cheers, Stefano
