Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Dave, Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. We've addressed this with the latest patch series, which I sent earlier today. vSockets now has support for pluggable transports, of which VMCI happens to be the first; all transport code is separated out into its own module. So the core is now hypervisor neutral. Given that, would you be willing to re-consider it, please? If at all possible, we'd like to make the current merge window. Thanks so much! - Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) I sent out a patch series this morning that splits out our code into a core part, containing the socket family/operations, and a VMCI-specific part. The core makes callbacks via a new transport layer into VMCI. It's not perfect -- there's still some cruft in the core socket structure -- but it lays the foundation of a hypervisor-neutral channel, and hopefully we can build on this with your help. It'd be great if you could take a look. Thanks! - Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On 01/09/13 03:22, Dmitry Torokhov wrote: On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote: I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. Objectively speaking neither solution is hypervisor neutral as there are hypervisors that implement either VMCI or virtio or something else entirely. Indeed. vmchannel is tied to virtio like vsock is tied to vmci. Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) And in the meantime, are there any other glaring errors that we need to address? Thanks! - Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 0/6] VSOCK for Linux upstreaming
* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012 15:47:14 -0800 Re: [PATCH 07/12] VMCI: queue pairs implementation. chckpatch sanity checking. - Fix vmci_get_contextid naming error. - Remove ASSERT/BUG_ON for vmci and vsock source codes. This addresses ddress Greg's comment on On 15 Nov 2012 15:47:14 -0800 Re: [PATCH 02/12] VMCI: datagram implementation. Remove all BUG_ON(), asserts. - use standard Linux kernel ioctl interface. This addresses Greg's comment on On Thu, 15 Nov 2012 16:01:18 -0800 Re: [PATCH 12/12] VMCI: Some header and config files. use linux in-kernel IO macros for VMCI. - Add vmci ioctl code entry in ioctl-number.txt. - Remove printk from header file. Align properly for macro PCI_VENDOR_ID_VMWARE. Remove #define for VMCI_DRIVER_VERSION_STRING. Remove #define for MODULE_NAME. Remove #define for pr_fmt and #define ASSERT(x). Remove inline function VMCI_MAKE_HANDLE and vmci_make_handle which return a structure on stack. use macro instead and use C99 initialization. Remove #define for VMCI_HANDLE_TO_CONTEXT_ID and VMCI_HANDLE_TO_RESOURCE_ID Change macro to inline function for VMCI_HANDLE_EQUAL. Remove u32 typedefs for vmci_id, vmci_event, vmci_privilege_flags. Use C99 style initialization for struct VMCI_INVALID_HANDLE. Use inline function instead of macro for VMCI_HANDLE_INVALID. No change for vmw_vmci_api.h location (under include/linux/ directory). No change for macros VMCI_CONTEXT_IS_VM, VMCI_HOST_CONTEXT_ID, VMCI_RESERVED_CID_LIMIT, VMCI_HYPERVISOR_CONTEXT_ID and VMCI_WELL_KNOWN_CONTEXT_ID. Still in header file include/linux/vmw_vmci_defs.h This addresses Greg's several comments on Thu, 15 Nov 2012 16:01:18 -0800 Re: [PATCH 12/12] VMCI: Some header and config files. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in an early post. * * * VMCI Sockets allows virtual machines to communicate with host kernel modules and the VMware hypervisors. VMCI Sockets kernel module has dependency on VMCI kernel module. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets API which facilitates fast and efficient communication between guest virtual machines and their host. A socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. The VMware VMCI Sockets are similar to other socket types, like Berkeley UNIX socket interface. The VMCI sockets module supports both connection-oriented stream sockets like TCP, and connectionless datagram sockets like UDP. The VSOCK protocol family is defined as AF_VSOCK and the socket operations split for SOCK_DGRAM and SOCK_STREAM. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (6): VSOCK: vsock protocol implementation. VSOCK: vsock address implementaion. VSOCK: notification implementation. VSOCK: statistics implementation. VSOCK: utility functions. VSOCK: header and config files. Documentation/ioctl/ioctl-number.txt |1 include/linux/socket.h |4 net/Kconfig |1 net/Makefile |1 net/vmw_vsock/Kconfig| 14 net/vmw_vsock/Makefile |4 net/vmw_vsock/af_vsock.c | 3279 ++
Re: [PATCH 0/6] VSOCK for Linux upstreaming
On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, and now that I've taken the VMCI patches that these depend on through my char-misc tree, can I take these as well? thanks, greg k-h ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
From: Greg KH gre...@linuxfoundation.org Date: Tue, 8 Jan 2013 16:21:10 -0800 On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, Really? I'd like to see where I did that. Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 So definitely NACK this code and any infrastructure you've merged which essentialy depends upon it. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: From: Greg KH gre...@linuxfoundation.org Date: Tue, 8 Jan 2013 16:21:10 -0800 On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, Really? I'd like to see where I did that. Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. So definitely NACK this code and any infrastructure you've merged which essentialy depends upon it. No, there is no infrastructure that depends on VSOCK, as VSOCK is built on top of VMCI, not the other way around. Thanks, Dmitry ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Dmitry Torokhov d...@vmware.com Date: Tue, 08 Jan 2013 17:41:44 -0800 On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: From: Greg KH gre...@linuxfoundation.org Date: Tue, 8 Jan 2013 16:21:10 -0800 On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, Really? I'd like to see where I did that. Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote: From: Dmitry Torokhov d...@vmware.com Date: Tue, 08 Jan 2013 17:41:44 -0800 On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: From: Greg KH gre...@linuxfoundation.org Date: Tue, 8 Jan 2013 16:21:10 -0800 On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, Really? I'd like to see where I did that. Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. Objectively speaking neither solution is hypervisor neutral as there are hypervisors that implement either VMCI or virtio or something else entirely. Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, and on this basis we ask to include VSOCK. Thanks, Dmitry ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Anthony, This was already done in a hypervisor neutral way using virtio: http://lists.openwall.net/netdev/2008/12/14/8 The concept was Nacked and that led to the abomination of virtio-serial. If an address family for virtualization is on the table, we should reconsider AF_VMCHANNEL. I finally had a look at your patch. Please correct me if I'm wrong, but it seems that the peer of an AF_VMCHANNEL connection is a virtio channel inside the hypervisor, i.e., the other end is _not_ sockets, right? That's quite a bit different from vSockets, where both sides use the socket interface, even within the VMX process in our hypervisor. We also intend for arbitrary host processes -- those outside the hypervisor -- to use it via the sockets interface. We have shipping applications that do just that, where communication is between a guest process and a host service, with both sides using the standard socket API but with the vSockets address family. We also encourage people to write such VM-to-host applications, and we've been shipping the vSockets header in our host-side products to allow people to do just that. So I think in that sense vSockets is somewhat more general, and we'd obviously prefer to go with our socket family and address structure if LKML is open to something like this. Thanks! - Andy PS I realize we still owe LKML a spec for the vSockets protocol. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 0/6] VSOCK for Linux upstreaming
* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a complex macro in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in an early post. * * * VMCI Sockets allows virtual machines to communicate with host kernel modules and the VMware hypervisors. VMCI Sockets kernel module has dependency on VMCI kernel module. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets API which facilitates fast and efficient communication between guest virtual machines and their host. A socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. The VMware VMCI Sockets are similar to other socket types, like Berkeley UNIX socket interface. The VMCI sockets module supports both connection-oriented stream sockets like TCP, and connectionless datagram sockets like UDP. The VSOCK protocol family is defined as AF_VSOCK and the socket operations split for SOCK_DGRAM and SOCK_STREAM. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (6): VSOCK: vsock protocol implementation. VSOCK: vsock address implementaion. VSOCK: notification implementation. VSOCK: statistics implementation. VSOCK: utility functions. VSOCK: header and config files. include/linux/socket.h |4 net/Kconfig |1 net/Makefile|1 net/vmw_vsock/Kconfig | 14 net/vmw_vsock/Makefile |4 net/vmw_vsock/af_vsock.c| 4054 +++ net/vmw_vsock/af_vsock.h| 180 ++ net/vmw_vsock/notify.c | 983 net/vmw_vsock/notify.h | 130 + net/vmw_vsock/notify_qstate.c | 625 + net/vmw_vsock/stats.c | 37 net/vmw_vsock/stats.h | 217 ++ net/vmw_vsock/util.c| 620 + net/vmw_vsock/util.h| 314 +++ net/vmw_vsock/vmci_sockets.h| 517 net/vmw_vsock/vmci_sockets_packet.h | 90 + net/vmw_vsock/vsock_addr.c | 246 ++ net/vmw_vsock/vsock_addr.h | 40 net/vmw_vsock/vsock_common.h| 127 + net/vmw_vsock/vsock_packet.h| 124 + net/vmw_vsock/vsock_version.h | 28 21 files changed, 8355 insertions(+), 1 deletions(-) create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/notify.c create mode 100644 net/vmw_vsock/notify.h create mode 100644 net/vmw_vsock/notify_qstate.c create mode 100644 net/vmw_vsock/stats.c create mode 100644 net/vmw_vsock/stats.h create mode 100644 net/vmw_vsock/util.c create mode 100644 net/vmw_vsock/util.h create mode 100644 net/vmw_vsock/vmci_sockets.h create mode 100644 net/vmw_vsock/vmci_sockets_packet.h create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_common.h create mode 100644 net/vmw_vsock/vsock_packet.h create mode 100644 net/vmw_vsock/vsock_version.h -- Signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On 11/07/2012 12:58 AM, Gerd Hoffmann wrote: On 11/05/12 19:19, Andy King wrote: Hi David, The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? Do you mean the VMCI calls? The VMCI driver is in the process of being upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is actively reviewing that code and we are addressing feedback. Also, there was some interest from RedHat into using vSockets as a unified interface, routed over a hypervisor-specific transport (virtio or otherwise, although for now VMCI is the only one implemented). Can you outline how this can be done? From a quick look over the code it seems like vsock has a hard dependency on vmci, is that correct? When making vsock a generic, reusable kernel service it should be the other way around: vsock should provide the core implementation and an interface where hypervisor-specific transports (vmci, virtio, xenbus, ...) can register themself. This was already done in a hypervisor neutral way using virtio: http://lists.openwall.net/netdev/2008/12/14/8 The concept was Nacked and that led to the abomination of virtio-serial. If an address family for virtualization is on the table, we should reconsider AF_VMCHANNEL. I'd be thrilled to get rid of virtio-serial... Regards, Anthony Liguori cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Sasha, Thanks for taking a look. So all the documentation I see in the VMCI Socket Programming Guide is about userspace programming, and the documentation in af_vsock.c is all around implementation considerations. Agreed, we're sorely lacking in proper documentation for the internal protocol. We're in the process of writing such a specification and will post it to LKML next week at the latest. example, whats the deal with REQUEST/REQUEST2? it appears like something to deal with legacy code, but I'd really like to have it documented somewhere instead of trying to figure how everything Correct, we have a legacy protocol and a v2, the latter now being the default. This particular packet is sent by the client when initiating a STREAM connection. The sequence is REQUEST(2)- NEGOTIATE(2)-OFFER-ACCEPT. It will be properly documented in the specification we post next week. Thanks! - Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Gerd, Also, there was some interest from RedHat into using vSockets as a unified interface, routed over a hypervisor-specific transport (virtio or otherwise, although for now VMCI is the only one implemented). Can you outline how this can be done? From a quick look over the code it seems like vsock has a hard dependency on vmci, is that correct? That's correct, VMCI is wired into vSockets and we don't currently provide any way to insert another transport. When making vsock a generic, reusable kernel service it should be the other way around: vsock should provide the core implementation and an interface where hypervisor-specific transports (vmci, virtio, xenbus, ...) can register themself. Sorry, that was a bad explanation on my part. You're absolutely correct as to how it _should_ work. But it's up to Red Hat or others to get the ball rolling and motivate the necessary work on vSockets to make this happen. As Greg says, everyone is lazy and just wants their code accepted ;) Thanks! - Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 0/6] VSOCK for Linux upstreaming
* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Fix some new sparse issues. - Remove some unneeded casts for VMCI. - add more __user annotations for VMCI. - Remove kernel version-specific bits from vSockets. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in an early post. * * * VMCI Sockets allows virtual machines to communicate with host kernel modules and the VMware hypervisors. VMCI Sockets kernel module has dependency on VMCI kernel module. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets API which facilitates fast and efficient communication between guest virtual machines and their host. A socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. The VMware VMCI Sockets are similar to other socket types, like Berkeley UNIX socket interface. The VMCI sockets module supports both connection-oriented stream sockets like TCP, and connectionless datagram sockets like UDP. The VSOCK protocol family is defined as AF_VSOCK and the socket operations split for SOCK_DGRAM and SOCK_STREAM. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (6): VSOCK: vsock protocol implementation. VSOCK: vsock address implementaion. VSOCK: notification implementation. VSOCK: statistics implementation. VSOCK: utility functions. VSOCK: header and config files. include/linux/socket.h |4 net/Kconfig |1 net/Makefile|1 net/vmw_vsock/Kconfig | 14 net/vmw_vsock/Makefile |4 net/vmw_vsock/af_vsock.c| 4135 +++ net/vmw_vsock/af_vsock.h| 179 ++ net/vmw_vsock/notify.c | 984 net/vmw_vsock/notify.h | 130 + net/vmw_vsock/notify_qstate.c | 627 + net/vmw_vsock/stats.c | 37 net/vmw_vsock/stats.h | 219 ++ net/vmw_vsock/util.c| 626 + net/vmw_vsock/util.h| 312 +++ net/vmw_vsock/vmci_sockets.h| 517 net/vmw_vsock/vmci_sockets_packet.h | 106 + net/vmw_vsock/vsock_addr.c | 264 ++ net/vmw_vsock/vsock_addr.h | 40 net/vmw_vsock/vsock_common.h| 130 + net/vmw_vsock/vsock_packet.h| 131 + net/vmw_vsock/vsock_version.h | 29 21 files changed, 8489 insertions(+), 1 deletions(-) create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/notify.c create mode 100644 net/vmw_vsock/notify.h create mode 100644 net/vmw_vsock/notify_qstate.c create mode 100644 net/vmw_vsock/stats.c create mode 100644 net/vmw_vsock/stats.h create mode 100644 net/vmw_vsock/util.c create mode 100644 net/vmw_vsock/util.h create mode 100644 net/vmw_vsock/vmci_sockets.h create mode 100644 net/vmw_vsock/vmci_sockets_packet.h create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_common.h create mode 100644 net/vmw_vsock/vsock_packet.h create mode 100644 net/vmw_vsock/vsock_version.h -- Signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
On Mon, 05 Nov 2012 10:00:38 -0800 George Zhang georgezh...@vmware.com wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Add include/linux/socket.h for AF_VSOCK. - Cleanup some comments. - Cleanup makefiles. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in an early post. * * * VMCI Sockets allows virtual machines to communicate with host kernel modules and the VMware hypervisors. VMCI Sockets kernel module has dependency on VMCI kernel module. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets API which facilitates fast and efficient communication between guest virtual machines and their host. A socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. The VMware VMCI Sockets are similar to other socket types, like Berkeley UNIX socket interface. The VMCI sockets module supports both connection-oriented stream sockets like TCP, and connectionless datagram sockets like UDP. The VSOCK protocol family is defined as AF_VSOCK and the socket operations split for SOCK_DGRAM and SOCK_STREAM. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. This should go to netdev as well since it is a new address family. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
Never mind, mail server seemed to be overloaded today. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On 11/05/12 19:19, Andy King wrote: Hi David, The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? Do you mean the VMCI calls? The VMCI driver is in the process of being upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is actively reviewing that code and we are addressing feedback. Also, there was some interest from RedHat into using vSockets as a unified interface, routed over a hypervisor-specific transport (virtio or otherwise, although for now VMCI is the only one implemented). Can you outline how this can be done? From a quick look over the code it seems like vsock has a hard dependency on vmci, is that correct? When making vsock a generic, reusable kernel service it should be the other way around: vsock should provide the core implementation and an interface where hypervisor-specific transports (vmci, virtio, xenbus, ...) can register themself. cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 0/6] VSOCK for Linux upstreaming
* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Add include/linux/socket.h for AF_VSOCK. - Cleanup some comments. - Cleanup makefiles. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in an early post. * * * VMCI Sockets allows virtual machines to communicate with host kernel modules and the VMware hypervisors. VMCI Sockets kernel module has dependency on VMCI kernel module. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets API which facilitates fast and efficient communication between guest virtual machines and their host. A socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. The VMware VMCI Sockets are similar to other socket types, like Berkeley UNIX socket interface. The VMCI sockets module supports both connection-oriented stream sockets like TCP, and connectionless datagram sockets like UDP. The VSOCK protocol family is defined as AF_VSOCK and the socket operations split for SOCK_DGRAM and SOCK_STREAM. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (6): VSOCK: vsock protocol implementation. VSOCK: vsock address implementaion. VSOCK: notification implementation. VSOCK: statistics implementation. VSOCK: utility functions. VSOCK: header and config files. include/linux/socket.h |4 net/Kconfig |1 net/Makefile|1 net/vmw_vsock/Kconfig | 14 net/vmw_vsock/Makefile |4 net/vmw_vsock/af_vsock.c| 4165 +++ net/vmw_vsock/af_vsock.h| 179 ++ net/vmw_vsock/notify.c | 984 net/vmw_vsock/notify.h | 130 + net/vmw_vsock/notify_qstate.c | 627 + net/vmw_vsock/stats.c | 37 net/vmw_vsock/stats.h | 219 ++ net/vmw_vsock/util.c| 626 + net/vmw_vsock/util.h| 312 +++ net/vmw_vsock/vmci_sockets.h| 517 net/vmw_vsock/vmci_sockets_packet.h | 106 + net/vmw_vsock/vsock_addr.c | 264 ++ net/vmw_vsock/vsock_addr.h | 40 net/vmw_vsock/vsock_common.h| 130 + net/vmw_vsock/vsock_packet.h| 131 + net/vmw_vsock/vsock_version.h | 29 21 files changed, 8519 insertions(+), 1 deletions(-) create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/notify.c create mode 100644 net/vmw_vsock/notify.h create mode 100644 net/vmw_vsock/notify_qstate.c create mode 100644 net/vmw_vsock/stats.c create mode 100644 net/vmw_vsock/stats.h create mode 100644 net/vmw_vsock/util.c create mode 100644 net/vmw_vsock/util.h create mode 100644 net/vmw_vsock/vmci_sockets.h create mode 100644 net/vmw_vsock/vmci_sockets_packet.h create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_common.h create mode 100644 net/vmw_vsock/vsock_packet.h create mode 100644 net/vmw_vsock/vsock_version.h -- Signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
From: David Miller da...@davemloft.net Date: Mon, 05 Nov 2012 13:09:17 -0500 (EST) The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? And BTW vm-crosst...@vmware.com bounces, take it out of the CC: list on all future emails. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi David, The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? Do you mean the VMCI calls? The VMCI driver is in the process of being upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is actively reviewing that code and we are addressing feedback. Also, there was some interest from RedHat into using vSockets as a unified interface, routed over a hypervisor-specific transport (virtio or otherwise, although for now VMCI is the only one implemented). Thanks! - Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
Hi George, On Mon, Nov 5, 2012 at 1:00 PM, George Zhang georgezh...@vmware.com wrote: For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. Is there documentation about the protocol itself? I couldn't find it on the link above. Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
David, We will fix this bounces and remove the email: crosst...@vmware.com. Thanks, george zhang - Original Message - From: David Miller da...@davemloft.net To: georgezh...@vmware.com Cc: net...@vger.kernel.org, linux-ker...@vger.kernel.org, virtualization@lists.linux-foundation.org, pv-driv...@vmware.com, vm-crosst...@vmware.com, gre...@linuxfoundation.org Sent: Monday, November 5, 2012 10:10:37 AM Subject: Re: [PATCH 0/6] VSOCK for Linux upstreaming From: David Miller da...@davemloft.net Date: Mon, 05 Nov 2012 13:09:17 -0500 (EST) The big and only question is whether anyone can actually use any of this stuff without your proprietary bits? And BTW vm-crosst...@vmware.com bounces, take it out of the CC: list on all future emails. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/6] VSOCK for Linux upstreaming
Sasha, There is a 'brief' implementation notes aboutVSOCK protocol family in af_vsock.c. More about user space layer socket programming is from VMCI Socket Programming Guide. (remove crosst...@vmware.com for email bouncing). thanks, George - Original Message - From: Sasha Levin levinsasha...@gmail.com To: George Zhang georgezh...@vmware.com Cc: net...@vger.kernel.org, linux-ker...@vger.kernel.org, virtualization@lists.linux-foundation.org, pv-driv...@vmware.com, vm-crosst...@vmware.com, da...@davemloft.net, gre...@linuxfoundation.org Sent: Monday, November 5, 2012 10:23:02 AM Subject: Re: [PATCH 0/6] VSOCK for Linux upstreaming Hi George, On Mon, Nov 5, 2012 at 1:00 PM, George Zhang georgezh...@vmware.com wrote: For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. Is there documentation about the protocol itself? I couldn't find it on the link above. Thanks, Sasha ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 0/6] VSOCK for Linux upstreaming
* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in an early post. * * * VMCI Sockets allows virtual machines to communicate with host kernel modules and the VMware hypervisors. VMCI Sockets kernel module has dependency on VMCI kernel module. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets API which facilitates fast and efficient communication between guest virtual machines and their host. A socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. The VMware VMCI Sockets are similar to other socket types, like Berkeley UNIX socket interface. The VMCI sockets module supports both connection-oriented stream sockets like TCP, and connectionless datagram sockets like UDP. The VSOCK protocol family is defined as AF_VSOCK and the socket operations split for SOCK_DGRAM and SOCK_STREAM. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (6): VSOCK: vsock protocol implementation. VSOCK: vsock address implementaion. VSOCK: notification implementation. VSOCK: statistics implementation. VSOCK: utility functions. VSOCK: header and config files. net/Kconfig |1 net/Makefile|1 net/vmw_vsock/Kconfig | 14 net/vmw_vsock/Makefile |8 net/vmw_vsock/af_vsock.c| 4259 +++ net/vmw_vsock/af_vsock.h| 179 + net/vmw_vsock/notify.c | 1041 + net/vmw_vsock/notify.h | 130 + net/vmw_vsock/notify_qstate.c | 670 ++ net/vmw_vsock/stats.c | 37 net/vmw_vsock/stats.h | 222 ++ net/vmw_vsock/util.c| 694 ++ net/vmw_vsock/util.h| 331 +++ net/vmw_vsock/vmci_sockets.h| 517 net/vmw_vsock/vmci_sockets_packet.h | 107 + net/vmw_vsock/vsock_addr.c | 264 ++ net/vmw_vsock/vsock_addr.h | 40 net/vmw_vsock/vsock_common.h| 130 + net/vmw_vsock/vsock_packet.h| 131 + net/vmw_vsock/vsock_version.h | 29 20 files changed, 8805 insertions(+), 0 deletions(-) create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/notify.c create mode 100644 net/vmw_vsock/notify.h create mode 100644 net/vmw_vsock/notify_qstate.c create mode 100644 net/vmw_vsock/stats.c create mode 100644 net/vmw_vsock/stats.h create mode 100644 net/vmw_vsock/util.c create mode 100644 net/vmw_vsock/util.h create mode 100644 net/vmw_vsock/vmci_sockets.h create mode 100644 net/vmw_vsock/vmci_sockets_packet.h create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_common.h create mode 100644 net/vmw_vsock/vsock_packet.h create mode 100644 net/vmw_vsock/vsock_version.h -- Signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
