From: Jorgen S. Hansen [mailto:jhansen@vmware.com]

quoted

On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi [off-list ref]

wrote:

quoted

...
We *can* by looking at the destination CID.  Please take a look at
drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI

handles

quoted

nested virt.

It boils down to something like this:

 static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
                                 int addr_len, int flags)
 {
     ...
     if (remote_addr.svm_cid == VMADDR_CID_HOST)
         transport = host_transport;
     else
         transport = guest_transport;

It's easy for connect(2) but Jorgen mentioned it's harder for listen(2)
because the socket would need to listen on both transports.  We define
two new constants VMADDR_CID_LISTEN_FROM_GUEST and
VMADDR_CID_LISTEN_FROM_HOST for bind(2) so that applications can

decide

quoted

which side to listen on.

If a socket is bound to VMADDR_CID_HOST, we would consider that socket as
bound to the host side transport, so that would be the same as
VMADDR_CID_LISTEN_FROM_GUEST. For the guest, we have
IOCTL_VM_SOCKETS_GET_LOCAL_CID, so that could be used to get and bind
a socket to the guest transport (VMCI will always return the guest CID as the
local one, if the VMCI driver is used in a guest, and it looks like virtio will do
the same). We could treat VMADDR_CID_ANY as always being the guest
transport, since that is the use case where you don’t know upfront what
your CID is, if we don’t want to listen on all transports. So we would use the
host transport, if a socket is bound to VMADDR_CID_HOST, or if there is no
guest transport, and in all other cases use the guest transport. However,
having a couple of symbolic names like you suggest certainly makes it more
obvious, and could be used in combination with this. It would be a plus if
existing applications would function as intended in most cases.

quoted

  Or the listen socket could simply listen to
both sides.

The only problem here would be the potential for a guest and a host app to
have a conflict wrt port numbers, even though they would be able to
operate fine, if restricted to their appropriate transport.

Thanks,
Jorgen

Hi Jorgen, Stefan,
Thank you for the detailed analysis!
You have a much better understanding than me about the complex
scenarios. Can you please work out a patch? :-)

IMO Linux driver of Hyper-V sockets is the simplest case, as we only have
the "to host" option (the host side driver of Hyper-V sockets runs on 
Windows kernel and I don't think the other hypervisors emulate
the full Hyper-V VMBus 4.0, which is required to support Hyper-V sockets).

-- Dexuan