OpenFloo: Fast Communication Channels between VMs
Project Members: Chirayu Shah, Jitesh Shah, Ketaki Kulkarni, Vedang Manerikar
We use Co-Linux, wherein virtualisation is made possible at ring 0. The Host OS and the guest OS co-operate at ring 0 to share available resources.
When multiple OS run parallely in a virtualized environment, the problem of communication between them arises. Typically the communication problem is solved by assigning a Virtual IP address to each virtual machine and proceeding with the TCP/IP protocol. But, the network stacks visibly slow down the communication speeds. Also, a major part of the TCP/IP protocol include error handling anf flow control. This is clearly not required in this particular case. So, another mechanism for fast message passing between the OS is desired.
We propose a method for communication between these guests through shared memory. As, network stack is totally bypassed we expect a vast speedup in communication.
In order to replace the TCP/IP backend with the shared memory module, we have to share pages between the two OS. Server allocates a new page whereas the client maps the page into its own page tables. Following are some important points:
- The interface designed should be as similar to the network calls as possible. It can then be integrated with the network stack, as an alternative method of transferring packets, so that applications do not need to change.
- Keeping that in mind, we use the client-server model. A server listens to a handle (similar to port in the TCP/IP context). A client can connect to the handle and thus, establish a communication path. A page will be shared among the communicating OS.
- Handles are global identifiers for communication paths. A handle should be able to uniquely identify the communicating OS, the page shared among them and the processes involved in the communication.
Inter-OS sleep/wakeup When a writer writes to the shared page, the reader (possibly in another OS) should be woken up. The problem with this is that wake-up lists cannot be maintained across OS. We use the passage page for the purpose.
Whenever, a guest wants to wake-up a process of another guest OS, it sets a bit in the passage page of the other guest OS. In the schedule() function of the guest OS, we check the bit. If 0, we continue with the usual code. Else, the appropriate process is woken up.
Sharing a page The alloc_page() call in the guest OS actually gets the page from the host OS. So, some method to inform the host OS that the page being asked for is for shared memory communication is required. We use the GFP flags to indicate such allocations. The host OS can take appropriate actions when it receives such requests.