On Mon, Jul 06, 2015 at 07:39:35AM -0700, Dexuan Cui wrote: > Hyper-V VM Sockets (hvsock) is a byte-stream based communication mechanism > between Windowsd 10 (or later) host and a guest. It's kind of TCP over > VMBus, but the transportation layer (VMBus) is much simpler than IP. > With Hyper-V VM Sockets, applications between the host and a guest can > talk with each other directly by the traditional BSD-style socket APIs. > > The patchset implements the necessary support in the guest side by adding > the necessary new APIs in the vmbus driver, and introducing a new driver > hv_sock.ko, which implements_a new socket address family AF_HYPERV. > > > I know the kernel has already had a VM Sockets driver (AF_VSOCK) based > on VMware's VMCI (net/vmw_vsock/, drivers/misc/vmw_vmci), and KVM is > proposing AF_VSOCK of virtio version: > http://thread.gmane.org/gmane.linux.network/365205. > > However, though Hyper-V VM Sockets may seem conceptually similar to > AF_VOSCK, there are differences in the transportation layer, and IMO these > make the direct code reusing impractical: > > 1. In AF_VSOCK, the endpoint type is: <u32 ContextID, u32 Port>, but in > AF_HYPERV, the endpoint type is: <GUID VM_ID, GUID ServiceID>. Here GUID > is 128-bit. > > 2. AF_VSOCK supports SOCK_DGRAM, while AF_HYPERV doesn't. > > 3. AF_VSOCK supports some special sock opts, like SO_VM_SOCKETS_BUFFER_SIZE, > SO_VM_SOCKETS_BUFFER_MIN/MAX_SIZE and SO_VM_SOCKETS_CONNECT_TIMEOUT. > These are meaningless to AF_HYPERV. > > 4. Some AF_VSOCK's VMCI transportation ops are meanless to AF_HYPERV/VMBus, > like .notify_recv_init > .notify_recv_pre_block > .notify_recv_pre_dequeue > .notify_recv_post_dequeue > .notify_send_init > .notify_send_pre_block > .notify_send_pre_enqueue > .notify_send_post_enqueue > etc. > > So I think we'd better introduce a new address family: AF_HYPERV. Points 2-4 are not critical. I think there are solutions to them. Point 1 is the main issue: hvsock has <GUID, GUID> addresses instead of vsock's <u32, u32> addresses. Perhaps a mapping could be used but that is pretty ugly. One idea is something like a userspace <GUID, GUID> <-> <u32, u32> lookup function that applications can use if they want to accept GUIDs. I don't have a workable alternative to propose, so I agree that a new address family is justified.
Attachment:
pgpuf38fN_qs2.pgp
Description: PGP signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
