Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Stephen Hemminger 
On Mon,  6 Jul 2015 07:47:29 -0700
Dexuan Cui de...@microsoft.com wrote:

 Hyper-V VM sockets (hvsock) supplies a byte-stream based communication
 mechanism between the 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.
 
 Hyper-V VM Sockets is only available on Windows 10 host and later. The
 patch implements the necessary support in the guest side by introducing
 a new socket address family AF_HYPERV.
 
 Signed-off-by: Dexuan Cui de...@microsoft.com

Is there any chance that AF_VSOCK could be used with different transport
for VMware and Hyper-V. Better to make guest applications host independent.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Paul Bolle 
Just two nits.

On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
 --- /dev/null
 +++ b/net/hv_sock/Kconfig

 +config HYPERV_SOCK
 + tristate Microsoft Hyper-V Socket (EXPERIMENTAL)
 + depends on HYPERV
 + default m
 + help
 +   Hyper-V Socket is a socket protocol similar to TCP, allowing
 +   communication between a Linux guest and the host.
 +
 +   To compile this driver as a module, choose M here: the module
 +   will be called hv_sock. If unsure, say N.

It's a bit odd to advise to say N if one is unsure and set the default
to 'm' at the same time.

 --- /dev/null
 +++ b/net/hv_sock/af_hvsock.c

 +static int hvsock_init(void)
 +{
 + [...]
 +}
 +
 +static void hvsock_exit(void)
 +{
 + [...]
 +}
 +
 +module_init(hvsock_init);
 +module_exit(hvsock_exit);

Any specific reason not to mark these functions __init and __exit?

Thanks,


Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Dexuan Cui 
 -Original Message-
 From: Olaf Hering [mailto:o...@aepfle.de]
 Sent: Tuesday, July 7, 2015 18:10
 To: Dexuan Cui; Paul Bolle
 Cc: gre...@linuxfoundation.org; da...@davemloft.net;
 netdev@vger.kernel.org; linux-ker...@vger.kernel.org; driverdev-
 de...@linuxdriverproject.org; a...@canonical.com; jasow...@redhat.com; KY
 Srinivasan; Haiyang Zhang
 Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
 
 On Tue, Jul 07, Paul Bolle wrote:
 
  On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
   --- /dev/null
   +++ b/net/hv_sock/Kconfig
 
   +config HYPERV_SOCK
   + tristate Microsoft Hyper-V Socket (EXPERIMENTAL)
   + depends on HYPERV
   + default m
 
  It's a bit odd to advise to say N if one is unsure and set the default
  to 'm' at the same time.
 
 The 'default' line has to be removed IMO.
 
 Olaf

OK, removing the line seems better than 'default n', though both reproduce
the same # CONFIG_HYPERV_SOCK is not set.

-- Dexuan

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Dexuan Cui 
 -Original Message-
 From: Paul Bolle
 Sent: Tuesday, July 7, 2015 17:38
 To: Dexuan Cui
 Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
 
 Just two nits.
 
 On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
  --- /dev/null
  +++ b/net/hv_sock/Kconfig
 
  +config HYPERV_SOCK
  +   tristate Microsoft Hyper-V Socket (EXPERIMENTAL)
  +   depends on HYPERV
  +   default m
  +   help
  + Hyper-V Socket is a socket protocol similar to TCP, allowing
  + communication between a Linux guest and the host.
  +
  + To compile this driver as a module, choose M here: the module
  + will be called hv_sock. If unsure, say N.
 
 It's a bit odd to advise to say N if one is unsure and set the default
 to 'm' at the same time.
Hi Paul,
Thanks for the suggestion!
I'll change the 'default' to n in V2.

  --- /dev/null
  +++ b/net/hv_sock/af_hvsock.c
 
  +static int hvsock_init(void)
  +{
  +   [...]
  +}
  +
  +static void hvsock_exit(void)
  +{
  +   [...]
  +}
  +
  +module_init(hvsock_init);
  +module_exit(hvsock_exit);
 
 Any specific reason not to mark these functions __init and __exit?
 
 Paul Bolle
Thanks for pointing this out -- I missed that. 
I'll add __init and __exit in V2.

Thanks,
-- Dexuan
N�r��yb�X��ǧv�^�)޺{.n�+���z�^�)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Paul Bolle 
On di, 2015-07-07 at 10:20 +, Dexuan Cui wrote:
 OK, removing the line seems better than 'default n', though both 
 reproduce the same # CONFIG_HYPERV_SOCK is not set.

Speaking from memory (so chances are I'm forgetting some silly detail)
that is because
# CONFIG_FOO is not set

will be printed if FOO's dependencies are met and FOO either has a
prompt or a default of 'n'.

Hope this helps,


Paul Bolle
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Olaf Hering 
On Tue, Jul 07, Dexuan Cui wrote:

 OK, removing the line seems better than 'default n', though both reproduce
 the same # CONFIG_HYPERV_SOCK is not set.

Perhaps default VMBUS (or whatever syntax is needed) may be the way to
enable it conditionally.

Olaf
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Olaf Hering 
On Tue, Jul 07, Paul Bolle wrote:

 On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
  --- /dev/null
  +++ b/net/hv_sock/Kconfig
 
  +config HYPERV_SOCK
  +   tristate Microsoft Hyper-V Socket (EXPERIMENTAL)
  +   depends on HYPERV
  +   default m

 It's a bit odd to advise to say N if one is unsure and set the default
 to 'm' at the same time.

The 'default' line has to be removed IMO.

Olaf
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Dexuan Cui 
 -Original Message-
 From: Stephen Hemminger
 Sent: Wednesday, July 8, 2015 2:31
 Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

 On Mon,  6 Jul 2015 07:47:29 -0700
 Dexuan Cui de...@microsoft.com wrote:

  Hyper-V VM sockets (hvsock) supplies a byte-stream based communication
  mechanism between the 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.
 
  Hyper-V VM Sockets is only available on Windows 10 host and later. The
  patch implements the necessary support in the guest side by introducing
  a new socket address family AF_HYPERV.
 
  Signed-off-by: Dexuan Cui de...@microsoft.com

 Is there any chance that AF_VSOCK could be used with different transport
 for VMware and Hyper-V. Better to make guest applications host independent.

Hi Stephen,
Thanks for the question. I tried to do that (since AF_HYPERV and AF_VSOCK
are conceptually similar), but I found it would be impractical: I listed the
reasons in my cover letter of the patchset:
https://lkml.org/lkml/2015/7/6/431

IMO the biggest difference is the size of the endpoint (u128 vs. u32):
u32 ContextID, u32 Port in AF_VOSCK
vs.
u128 GUID_VM_ID, u128 GUID_ServiceID in AF_HYPERV.

In the current code of AF_VSOCK and the related transport layer (the wrapper
ops of VMware's VMCI), the size is widely used by struct sockaddr_vm (this
struct is also exported to the user space).

So, anyway, the user space application has to explicitly handle the different
endpoint size.

And in the driver side, I'm afraid there is no way to directly reuse the code of
AF_VSOCK with trivial change :-( , because we would have to make the
AF_VSOCK code be able to know the real sockaddr type (sockaddr_vm or
sockaddr_hv? The two structs have different layout and different field names)
at runtime and behave differently. This would make the code a mess, IMO.

That's why I think it would be better to introduce a new address family.

Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

2015-07-07 Thread Dexuan Cui 
 -Original Message-
 From: Olaf Hering
 Sent: Tuesday, July 7, 2015 18:59
 Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
 
 On Tue, Jul 07, Dexuan Cui wrote:
 
  OK, removing the line seems better than 'default n', though both reproduce
  the same # CONFIG_HYPERV_SOCK is not set.
 
 Perhaps default VMBUS (or whatever syntax is needed) may be the way to
 enable it conditionally.
 
 Olaf
Thanks, Olaf!
I think we can use default m if HYPERV.

Paul, I'll remove the sentence If unsure, say N.

 Thanks,
-- Dexuan