> From: Jorgen S. Hansen [mailto:jhansen@xxxxxxxxxx] > > On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi <stefanha@xxxxxxxxxx> > wrote: > > ... > > 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 > > 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 > > 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. > > > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
