Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1439156

[PATCH v15 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

Path csiph.com!feeder.erje.net!1.us.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From Dexuan Cui <decui@microsoft.com>
Newsgroups linux.kernel
Subject [PATCH v15 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
Date Fri, 08 Jul 2016 09:50:01 +0200
Message-ID <rSyHT-1K2-3@gated-at.bofh.it> (permalink)
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jpCF+8yILMX6NVJMoNfzc03fs8AnfDzKYVjcbzfzww4=; b=HLZbk7ydiN2z/HF+doiLnoHwQo4iHIa5NctsVB+riJWMHtRQ4wx6j0XcdY0yciweb/4Tx9oxDVQu/oQn6NHqWiQyPm+GBgVTfht1X3/Iyatm1WGdSgfvJ+ZGySyLRSRF5WH+/HwrCJaCLCp6vYU7ilFaLt5yuHC2AC29Nlkif44=
Thread-Topic [PATCH v15 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
Thread-Index AdHY7G88L39cf5yLQWCBIBEQKf3EXA==
Accept-Language en-US
Content-Language en-US
Authentication-Results spf=none (sender IP is ) smtp.mailfrom=decui@microsoft.com;
X-Originating-IP [2404:f801:9000:19::5e6]
X-Ms-Office365-Filtering-Correlation-ID 6bf6b46c-7b31-4689-d2a2-08d3a703b01e
X-Microsoft-Exchange-Diagnostics 1;CO2PR03MB2277;6:e17g4vQUFwqjm2ZHGwwYBY5OxLDr3oirB7BDvFpHcmwNCh1e0gsnQ42aaKyVXoWDuKfmzSY9hv9UdQqkaZrLyEzwDEzmr2gh+CLU1D1ofTLwU3Kw98dPmTOutW1BXcx/GNvljrDgmgtmGP3Y5soDUlFl7f6so7bm4rIeZjBKzAzmqlFdD4SrQ/9z5Kf/mETYJchFdb2g4q9N7+1s4iwSnyj6aerWMqqUbHKSuO5JmljR4AVOq1jiacPuHZ4fbDpeaL1MCFpIBn1KzFCU+BNtsmavJPA8kG06VnnvkKP7KBFoIZvnckTOdK9jqOaSEaEt/NCG24r+ZzH7reXdfAFBKQ==;5:/Dj0TXzEUUXYmaVWkkCqDpv8lX6BgpgR5ISQo/kZZNUeYhcgTaxpWp7ZP1okwCOLB0C/abUOzTTAOSEvGxFri5M28zBcpTMgxeYFD/MjfsrGH+p/fYJY13Fd0+pRtM/MGUlOusDkOrvRoxCRrLGmEA==;24:i3BGiJswQWAkzY3BrtAuyJp63CNXUG647CfRqhmlvXYwkgpkStWO0LnXeguseKLaD3phKEnguiinpenzxPTO5xODJzWz71lX/YbdDZ0wI08=;7:sZ5swwPtETGftFMGetVLa8rlhYQLT6w7vQs1uroS7qCIRKAczI94F85t76fvxuBgfrKTC4a3tqVzlty+DzJt0l/nzVwnpPMKdF3wGN61gWaEwORGZy1OHfXR+M306Wp2zMyg6iS47x7X1UuAIsdEWrjBuLDN2SQSZTr10EjanHbP7WaxSdNYTLj4z++fsc8deqvI7FKk8W4KItpDUfcBud2gqK067PsJW24jo4yiOkVKPWPuvX/fiAWp3ATS0Xxc
X-Microsoft-Antispam UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2277;
X-Microsoft-Antispam-Prvs <CO2PR03MB2277DD52064D4513D978F12CBF3C0@CO2PR03MB2277.namprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test UriScan:(158342451672863)(278428928389397)(166708455590820)(36064498253994)(788757137089)(176295241369792)(21532816269658);
X-Exchange-Antispam-Report-Cfa-Test BCL:0;PCL:0;RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038);SRVR:CO2PR03MB2277;BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB2277;
X-Forefront-Prvs 0997523C40
X-Forefront-Antispam-Report SFV:NSPM;SFS:(10019020)(6009001)(7916002)(209900001)(189002)(3905003)(199003)(5003600100003)(76576001)(106356001)(3660700001)(586003)(86612001)(81166006)(54356999)(97736004)(5002640100001)(101416001)(2900100001)(5001770100001)(81156014)(3280700002)(68736007)(19580395003)(74316002)(122556002)(8676002)(9686002)(99286002)(189998001)(305945005)(7696003)(15395725005)(1511001)(5005710100001)(4326007)(87936001)(229853001)(10400500002)(2421001)(33656002)(105586002)(92566002)(7736002)(7846002)(8936002)(8990500004)(50986999)(2561002)(86362001)(2906002)(15975445007)(2501003)(77096005)(102836003)(10090500001)(6116002)(11100500001)(10290500002)(2201001)(921003)(3826002)(1121003)(6606295002);DIR:OUT;SFP:1102;SCL:1;SRVR:CO2PR03MB2277;H:CO2PR03MB2182.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en;
Received-Spf None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Spamdiagnosticoutput 1:99
Spamdiagnosticmetadata NSPM
Content-Type text/plain; charset="us-ascii"
Content-Transfer-Encoding 8BIT
MIME-Version 1.0
X-Originatororg microsoft.com
X-Ms-Exchange-Crosstenant-Originalarrivaltime 08 Jul 2016 07:44:26.8750 (UTC)
X-Ms-Exchange-Crosstenant-Fromentityheader Hosted
X-Ms-Exchange-Crosstenant-ID 72f988bf-86f1-41af-91ab-2d7cd011db47
X-Ms-Exchange-Transport-Crosstenantheadersstamped CO2PR03MB2277
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 203
Organization linux.* mail to news gateway
X-Original-Cc Haiyang Zhang <haiyangz@microsoft.com>, Dave Scott <dave.scott@docker.com>
X-Original-Date Fri, 8 Jul 2016 07:44:26 +0000
X-Original-Message-ID <CO2PR03MB21820CED1742C063048CC9A0BF3C0@CO2PR03MB2182.namprd03.prod.outlook.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1439156

Show key headers only | View raw


Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It's somewhat like TCP over
VMBus, but the transportation layer (VMBus) is much simpler than IP.

With Hyper-V Sockets, applications between the host and the guest can talk
to each other directly by the traditional BSD-style socket APIs.

Hyper-V Sockets is only available on new Windows hosts, like Windows Server
2016. More info is in this article "Make your own integration services":
https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/develop/make_mgmt_service

The patch implements the necessary support in the guest side by
introducing a new socket address family AF_HYPERV.

You can also get the patch by:
https://github.com/dcui/linux/commits/decui/hv_sock/net-next/20160708_v15

Note: the VMBus driver side's supporting patches have been in the mainline
tree.

I know the kernel has already had a VM Sockets driver (AF_VSOCK) based
on VMware VMCI (net/vmw_vsock/, drivers/misc/vmw_vmci), and KVM is
proposing AF_VSOCK of virtio version:
http://marc.info/?l=linux-netdev&m=145952064004765&w=2

However, though Hyper-V 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.

Please review the patch.

Looking forward to your comments, especially comments from David. :-)

Changes since v1:
- updated "[PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature"
- added __init and __exit for the module init/exit functions
- net/hv_sock/Kconfig: "default m" -> "default m if HYPERV"
- MODULE_LICENSE: "Dual MIT/GPL" -> "Dual BSD/GPL"

Changes since v2:
- fixed various coding issue pointed out by David Miller
- fixed indentation issues
- removed pr_debug in net/hv_sock/af_hvsock.c
- used reverse-Chrismas-tree style for local variables.
- EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL

Changes since v3:
- fixed a few coding issue pointed by Vitaly Kuznetsov and Dan Carpenter
- fixed the ret value in vmbus_recvpacket_hvsock on error
- fixed the style of multi-line comment: vmbus_get_hvsock_rw_status()

Changes since v4 (https://lkml.org/lkml/2015/7/28/404):
- addressed all the comments about V4.
- treat the hvsock offers/channels as special VMBus devices
- add a mechanism to pass hvsock events to the hvsock driver
- fixed some corner cases with proper locking when a connection is closed
- rebased to the latest Greg's tree

Changes since v5 (https://lkml.org/lkml/2015/12/24/103):
- addressed the coding style issues (Vitaly Kuznetsov & David Miller, thanks!)
- used a better coding for the per-channel rescind callback (Thank Vitaly!)
- avoided the introduction of new VMBUS driver APIs vmbus_sendpacket_hvsock()
and vmbus_recvpacket_hvsock() and used vmbus_sendpacket()/vmbus_recvpacket()
in the higher level (i.e., the vmsock driver). Thank Vitaly!

Changes since v6 (http://lkml.iu.edu/hypermail/linux/kernel/1601.3/01813.html)
- only a few minor changes of coding style and comments

Changes since v7
- a few minor changes of coding style: thanks, Joe Perches!
- added some lines of comments about GUID/UUID before the struct sockaddr_hv.

Changes since v8
- removed the unnecessary __packed for some definitions: thanks, David!
- hvsock_open_connection:  use offer.u.pipe.user_def[0] to know the connection
and reorganized the function
direction 
- reorganized the code according to suggestions from Cathy Avery: split big
functions into small ones, set .setsockopt and getsockopt to
sock_no_setsockopt/sock_no_getsockopt
- inline'd some small list helper functions

Changes since v9
- minimized struct hvsock_sock by making the send/recv buffers pointers.
   the buffers are allocated by kmalloc() in __hvsock_create() now.
- minimized the sizes of the send/recv buffers and the vmbus ringbuffers.

Changes since v10

1) add module params: send_ring_page, recv_ring_page. They can be used to
enlarge the ringbuffer size to get better performance, e.g.,
# modprobe hv_sock  recv_ring_page=16 send_ring_page=16
By default, recv_ring_page is 3 and send_ring_page is 2.

2) add module param max_socket_number (the default is 1024).
A user can enlarge the number to create more than 1024 hv_sock sockets.
By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes.
(Here 1+1 means 1 page for send/recv buffers per connection, respectively.)

3) implement the TODO in hvsock_shutdown().

4) fix a bug in hvsock_close_connection():
   I remove "sk->sk_socket->state = SS_UNCONNECTED;" -- actually this line
is not really useful. For a connection triggered by a host app's connect(),
sk->sk_socket remains NULL before the connection is accepted by the server
app (in Linux VM): see hvsock_accept() -> hvsock_accept_wait() ->
sock_graft(connected, newsock). If the host app exits before the server
app's accept() returns, the host can send a rescind-message to close the
connection and later in the Linux VM's message handler 
i.e. vmbus_onoffer_rescind()), Linux will get a NULL de-referencing crash. 

5) fix a bug in hvsock_open_connection()
  I move the vmbus_set_chn_rescind_callback() to a later place, because
when vmbus_open() fails, hvsock_close_connection() can do nothing and we
count on vmbus_onoffer_rescind() -> vmbus_device_unregister() to clean up
the device.

6) some stylistic modificiation.


Changes since v11:
1) remove the module params as David suggested.

2) use 5 exact pages for VMBus send/recv rings, respectively.
The host side's design of the feature requires 5 exact pages for recv/send
rings respectively -- this is suboptimal considering memory consumption,
however unluckily we have to live with it, before the host comes up with
a new design in the future. :-(

3) remove the per-connection static send/recv buffers
Instead, we allocate and free the buffers dynamically only when we recv/send
data. This means: when a connection is idle, no memory is consumed as
recv/send buffers at all.
Dexuan Cui (1):
  hv_sock: introduce Hyper-V Sockets

Changes since v12:
return ENOMEM on buffer alllocation failure

   Actually "man read/write" says "Other errors may occur, depending on the
object connected to fd". "man send/recv" indeed lists ENOMEM.
   Considering AF_HYPERV is a new socket type, ENOMEM seems OK here.
   In the long run, I think we should add a new API in the VMBus driver,
allowing data copy from VMBus ringbuffer into user mode buffer directly.
This way, we can even eliminate this temporary buffer.

Changes since v13:
fix some coding style issues pointed out by David.

Changes since v14:
Just some stylistic changes addressing comments from Joe Perches and
Olaf Hering -- thank you!
- add a GPL blurb.
- define a new macro PAGE_SIZE_4K and use it to replace PAGE_SIZE
- change sk_to_hvsock/hvsock_to_sk() from macros to inline functions
- remove a not-very-useful pr_err()
- fix some typos in comment and coding style issues.


Dexuan Cui (1):
  hv_sock: introduce Hyper-V Sockets

 MAINTAINERS                 |    2 +
 include/linux/hyperv.h      |   13 +
 include/linux/socket.h      |    4 +-
 include/net/af_hvsock.h     |   78 +++
 include/uapi/linux/hyperv.h |   24 +
 net/Kconfig                 |    1 +
 net/Makefile                |    1 +
 net/hv_sock/Kconfig         |   10 +
 net/hv_sock/Makefile        |    3 +
 net/hv_sock/af_hvsock.c     | 1523 +++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 1658 insertions(+), 1 deletion(-)
 create mode 100644 include/net/af_hvsock.h
 create mode 100644 net/hv_sock/Kconfig
 create mode 100644 net/hv_sock/Makefile
 create mode 100644 net/hv_sock/af_hvsock.c

-- 
2.1.0

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

[PATCH v15 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) Dexuan Cui <decui@microsoft.com> - 2016-07-08 09:50 +0200

csiph-web