From KVM
Revision as of 13:59, 5 August 2015 by Paolo Bonzini (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. This time can also be used for hands-on hacking sessions.

If you are interested in organizing such a group time event, please add it to the list *before* KVM Forum, so people have time to organize which one they will attend.

All of these sessions will get the chance to quickly talk about results they managed to achieve during their time in a quick "results" session.

BoF Ideas

ivshmem / inter-VM shared memory based communication

Summary: ivshmem: towards a draft spec for inter-VM shared memory

The need to communicate efficiently between virtual machines is prominent for use cases involving high throughput, low latency requirements, for example at the edge of the telecom network in NFV.

At the moment multiple solutions are used, including large network packet processing frameworks, and also ad-hoc solutions, and often they make use of some form of ivshmem as the backend, either as a new implementation which mimics nehanni, or by directly making use of the ivshmem driver in QEMU.

There are multiple problems which need to be addressed regarding ivshmem.

1 - there is no specification or draft, or even single stable implementation to look at. The mechanism in different implementations is similar, ie the concept to expose the shared memory as PCI bars to the guest in some way, but the details differ.

2 - such specification or drafting effort should take into account different needs, including the requirement to mitigate the security aspects and implications of basing a design on shared memory, and may need to offer different profiles for different use cases (1 VM -> 1 VM pre-configured communication area, for example, vs globally shared memory region).

3 - to maximize its value, this building block should be independent of the frameworks and interfaces which currently make use of it, and also should not be tied to a single implementation, but instead be general enough, so that the same interface can be targeted by different hypervisor, OS and application programmers, and expect a valid result.


Links:

Nahanni: a shared memory interface for KVM: http://www.linux-kvm.org/images/e/e8/0.11.Nahanni-CamMacdonell.pdf

patch introducing ivshmem into QEMU: http://lwn.net/Articles/380869/

QEMU: http://wiki.qemu.org/Main_Page

Jailhouse, implementing ivshmem-like communication: https://github.com/siemens/jailhouse

NFV ETSI standards (use cases, architecture, infrastructure, compute, network and hypervisor)

http://www.etsi.org/standards-search?search=NFV&page=1&title=1&keywords=1&ed=1&sortby=1

People:

  • Claudio Fontana (Huawei Technologies Duesseldorf GmbH)
  • Veaceslav Falico (Munich ERC European Research Center)
  • Ajo Jose Panoor (Euler Department - Central Software Institute)

BoF idea template

=== TITLE ===

'''Summary:''' Short description of the idea

Detailed description of the idea.

'''Links:'''
* Wiki links to relevant material
* External links to mailing lists or web sites

'''People:'''
* Your Name (organizer)
* People that want to attend this session