1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

VMware Still Trying To Push VMCI, VSOCK For Linux

Virtualization

Published on 09 January 2013 05:56 PM EST
Written by Michael Larabel in Virtualization
Comment On This Article

VMware is still trying to push VMCI (the Virtual Machine Communication Interface) and VSOCK (VMCI Sockets) into the mainline Linux kernel. Fortunately, it looks like this virtualization code from the proprietary software vendor will make it into the Linux 3.9 kernel.

Going back to May of last year, VMCI for the mainline Linux kernel was talked about by VMware as one of their interests. VMware has published the patches multiple times, but to date the code hasn't landed in the kernel nor its staging area.

In July of 2012 it looked like VMCI might be ready to enter the mainline tree. It turned out that the code wasn't ready to be merged due to comments by other kernel developers. In October was another mainline attempt for VMCI/VSOCK, but that too didn't bear any fruit.

With a new year now comes a new attempt by VMware to mainline the Virtual Machine Communication Interface and VMCI Sockets. While VMCI/VSOCK is designed around VMware's needs of their commercial virtualization software, the code they are trying to push is obviously all open-source and they're trying to push this code in order to improve the "out of the box" Linux experience for VMware customers -- similar to Microsoft pushing Hyper-V Linux drivers.

For those that don't remember what VMware VMCI is all about:
VMCI allows virtual machines to communicate with host kernel modules and the VMware hypervisors. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets, 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.

In a virtual machine, VMCI is exposed as a regular PCI device. The primary communication mechanisms supported are a point-to-point bidirectional transport based on a pair of memory-mapped queues, and asynchronous notifications in the form of datagrams and doorbells. These features are available to kernel level components such as HGFS and VMCI Sockets through the VMCI kernel API. In addition to this, the VMCI kernel API provides support for receiving events related to the state of the VMCI communication channels, and the virtual machine itself.
Fortunately, this time around with the latest revisions to the VMware patches, it looks like they will make it into the mainline tree. Greg Kroah-Hartman has already responded to the VMCI patch-set, "Nice work, thanks for the changes you've made over time, and for your persistence. I can't see anything else to complain about, so I've applied this to my tree and it will show up in linux-next tomorrow or so."

However, when it comes to the VSOCK patches, David Miller has not acknowledged them. "...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. So definitely NACK this code and any infrastructure you've merged which essentialy depends upon it." After VMware attempted to clarify the infrastructure situation that VSOCK is just built atop VMCI, Miller added, "I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is."

The VMware answer there is that nothing is really hypervisor neutral. "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."

Those wanting to look at this VMware kernel code for upstreaming can find the six patches and comments on VSOCK in this thread while the twelve patches and comments for VMCI can be found in this thread.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  2. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  3. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  4. Sumo's Omni Gets Reloaded
Latest Linux Articles
  1. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
  2. Preview: OS X 10.10 Yosemite vs. Ubuntu Linux GPU Performance
  3. Radeon Graphics Yield Mixed Results With Linux 3.17 Kernel
  4. AMD's RadeonSI Driver Sped Up A Lot This Summer
Latest Linux News
  1. Google Chrome 37 Brings Many Security Fixes
  2. MenuetOS Updated With SMP Threads & Onscreen Keyboard
  3. Mesa Has A New Release Manager
  4. Enlightenment E19 Lands Its New Wayland Compositor Code
  5. Nouveau Turns Into A Mess In Latest Linux 3.17 + Mesa 10.3-dev Tests
  6. New GCC 5.0 Changes, Command-Line Options That Landed So Far
  7. SteamOS Update 133 Has Better Intel Performance, VA-API
  8. DRM Graphics Changes For Linux 3.18 Might End Up Being Smaller
  9. Ioquake3 Works On Finally Switching Over To SDL2
  10. Linux 3.17-rc2 Release Celebrates 23 Years Of Linux
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. AMD Releases UVD Video Decode Support For R600 GPUs
  3. Announcing radeontop, a tool for viewing the GPU usage
  4. Users defect to Linux as OpenBSD removes Lynx from base system
  5. Chinese People Try To Patent Wine On ARM
  6. American Citizens running AMOK for food stamps
  7. "The World's Most Highly-Assured OS" Kernel Open-Sourced
  8. What Linux Distribution Should Be Benchmarked The Most?