Google Summer of Code 2013

Introduction

QEMU has graciously been accepted as a mentoring organization for Google Summer of Code 2013. This page contains our ideas list and information for students and mentors.

Please note that QEMU, as a GSoC organization, also includes the following projects:

• The Linux Kernel's KVM module
• Libvirt, the virtualization library

Find Us

• IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
• IRC (development):
  • QEMU: #qemu on irc.oftc.net
  • Libvirt: #virt on irc.oftc.net
  • KVM: #kvm on chat.freenode.net
• Mailing list:
  • QEMU: http://lists.nongnu.org/mailman/listinfo/qemu-devel
  • Libvirt: http://www.redhat.com/mailman/listinfo/libvir-list
  • KVM: http://vger.kernel.org/vger-lists.html#kvm

Please contact the mentor for the project idea you are interested in. IRC is usually the quickest way to get an answer.

For general questions about QEMU in GSoC, please contact the following people:

• Stefan Hajnoczi (stefanha on IRC)
• Anthony Liguori (aliguori on IRC)

Important links

• FAQ
• Program Timeline
• Advice for Mentors

Information for students

Please contact the mentor before applying so we can arrange for an IRC interview and get to know each other. Students who do not contact the mentor cannot be accepted.

We require students to provide at least the following information in their applications:

• Contact information (email, irc nick, phone number)
• A general personal description (skills, past experiences and open source contributions, if any)
• Why QEMU and why this project
• A detailed description of the approach the student will take

Note: Submitting a patch and having it merged by QEMU or KVM increases your chances of being accepted.

Project Ideas

This is the listing of suggested project ideas. Students are free to suggest their own projects, too.

QEMU projects

Documentation tools

Summary: QEMU has documentation in several different formats. The goal is to reorganize the documentation to be more consistent and write new tools to help automatically generating documentation.

QEMU documentation seems very sparse, but there are actually several sources of documentation: two Texinfo manuals covering the command-line and code translators, several README files, various hardware specifications, GtkDoc comments, and QAPI documentation. The goal of this project is to write tools and scripts that process this content and generate helpful documentation in HTML or other formats.

Links:

• qemu-options.hx
• qapi-schema.json
• qemu-doc.texi
• scripts/ where existing tools live

Details:

• Skill level: beginner
• Language: Python, Shell
• Mentor: Paolo Bonzini <pbonzini@redhat.com> ("bonzini" on IRC)

Integrating Kconfig

Summary: QEMU is a large program and most of the time you do not want to build all of it. The project will provide a simple mechanism to configure QEMU

Configuration of QEMU is currently split between multiple configuration files (for guest features) and a configure script (for host features); there is no user interface to fill in the configuration files, and no way to express dependencies between features. The project seeks to adopt Linux's Kconfig in QEMU, and possibly to improve the granularity at which QEMU is configured.

If you want to see Kconfig in action, try "make menuconfig" with the Linux kernel source. It allows the user to enable or disable build components and handles dependencies.

Links:

• QEMU's configure script
• QEMU's top-level Makefile
• kbuild and kconfig documentation
• menuconfig on Wikipedia

Details:

• Skill level: beginner
• Language: Shell, Python, C
• Mentor: Paolo Bonzini <pbonzini@redhat.com> ("bonzini" on IRC)

Integrated Copy/Paste

Summary: Add guest copy/paste support to builtin QEMU UIs

Users have come to expect copy-paste between host and guest to work. This is also called clipboard sharing and makes it easier to work with graphical guests.

This project would start out integrating copy/paste APIs into qemu-ga. Copy/paste support is already available in the spice agents so those should serve as a starting point. Once qemu-ga can support copy/paste, it can then be plumbed through the VNC server and the GTK UI. Stretch goals would include drag and drop and/or Windows guest enablement

Links:

• Spice VD Agent: http://cgit.freedesktop.org/spice/linux/vd_agent/
• RFB Protocol: http://tigervnc.svn.sourceforge.net/viewvc/tigervnc/rfbproto/rfbproto.rst?content-type=text/plain
• GTK Clipboard: https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html

Details:

• Skill level: intermediate
• Language: C
• Mentor: Anthony Liguori <anthony@codemonkey.ws> ("aliguori" on IRC)
• Mentor: Mike Roth <mdroth@linux.vnet.ibm.com> ("mdroth" on IRC)
• Suggested by: Anthony Liguori

Continuous vmstate testing

Summary: QEMU devices have a way to serialize their state. The goal is to implement randomized save/reset/load device state tests.

QEMU can serialize state for its devices. This feature is used by migration and save to disk. We want to exercise that state to be sure that we are not missing state when we change device emulation code. Given a tree of the devices, we can randomly choose a device, save its state to a buffer, reset the device (state that it has after boot), and load the state back every n milliseconds. If it fails we know:

• which device is broken
• the state of the device
• what we were doing at the point of failure

By doing this project you will learn about live migration and device emulation. When your testing tool discovers bugs you can delve into the affected device to fix it yourself or you can file bugs to get help from the maintainers.

Details:

• Skill level: intermediate
• Language: C
• Mentor: Juan Quintela <quintela@redhat.com> ("quintela" on IRC)

Add USB Media Transfer Protocol emulation to QEMU

Summary: Flesh out the prototype of MTP emulation and get the working result merged into QEMU.

There is a USB Media Transfer Protocol prototype which supports linux hosts. Media Transfer Protocol is a USB protocol used to exchange files with cameras, audio players, and smartphones. It is particularly interesting for QEMU because modern guest operating systems support it out-of-the-box and it can be used to easily transfer files between the guest and host.

High priority tasks:

• Make it portable (i.e. work on windows hosts), evaluate options and implement it. Possible options: (1) create small posix/win32 abstraction layer for file+directory access, or (2) hook up virtfs code.
• Finishing touches to get it into mergable state (not that much, little cleanups here and there).

Medium priority tasks:

• Figure why Windows guests classify our MTP device as "Digital Camera" & fix it.
• Test with different guests / guest applications, fix issues as they pop up.

Useful features which can be added:

• Write support (current prototype is read-only).
• Quota (so the guest can't fill up the hosts disk, obviously depends on write support).
• Notification support: signal changes in the directory tree to the guest, so new/deleted files are instantly visible in the guest (probably hard to do in a efficient & portable way, maybe target linux+inotify).

For background information on MTP, see http://en.wikipedia.org/wiki/Media_Transfer_Protocol.

• Skill level: intermediate/advanced
• Language: C
• Mentor: Gerd Hoffmann <kraxel@redhat.com> ("kraxel" on IRC)

Improving the Win32 and Win64 ports of QEMU

Summary: QEMU supports Windows (both 32-bit and 64-bit), but the limited amount of testing caused performance to suffer and bugs to creep in release after release. This project aims at fixing QEMU bugs affecting Windows platforms, and adding new features such as migration.

• Skill level: intermediate/advanced
• Language: C
• Mentor: Paolo Bonzini <pbonzini@redhat.com> ("bonzini" on IRC)

Converting coroutines to Continuation Passing C

Summary: Integrate Continuation Passing C into QEMU as a drop-in replacement for coroutines.

QEMU implements coroutines using stack switching, which has proved fragile and hard to port. Continuation Passing C provides a similar programming model to coroutines without using stack switching.

This project attempts to replace coroutines with Continuation Passing C. Most effort will be in adapting Continuation Passing C and its runtime library to implement QEMU's coroutine API. Hopefully QEMU code changes will be minimal.

If the student has sufficient time they can explore reimplementing the Continuation Passing C translator in a format that is easier to consume - like a GCC patch or plugin.

This project is suitable for students interested in compilers and programming languages. This is a challenging project that requires listening to and working with the community.

Please take a look at the links below before getting in touch about this project.

Links:

• http://en.wikipedia.org/wiki/Coroutine
• QEMU's include/block/coroutine.h
• http://www.pps.univ-paris-diderot.fr/~kerneis/software/cpc/

Details:

• Skill level: advanced
• Language: C, OCaml (read-only)
• Mentors: Stefan Hajnoczi <stefanha@gmail.com> ("stefanha" on IRC), Gabriel Kerneis <gabriel.kerneis@cl.cam.ac.uk> ("kerneis_g" on IRC)

KVM projects

Improve nested virtualization support for x86

Summary: Improve nested virtualization support for Intel and AMD CPUs using test cases

Every wanted to write your own hypervisor? This is a unique chance! Granted, the result will "just" be test cases for KVM, but this will still allow to explore interesting aspects of the x86 architecture and learn a lot about CPU virtualization on x86 and how it is used by KVM. Precondition is an intermediate understanding of the x86 architecture, good C knowledge and experience with x86 assembly. The test cases shall be written within the kvm unit test framework. They have to establish an environment that allows switching a CPU into virtualization mode and running pieces of guest code, also provided by the tests. Those pieces shall trigger corner cases of nested virtualization reliably that are never or only rarely hit by standard hypervisors. If bugs in KVM are found, they should ideally be addressed as well. Foundation will be the Intel and AMD system programming manuals, but likely also intensive discussions about their interpretation in the community.

Links:

• kvm unit tests
• Intel architecture manuals
• AMD64 architecture manuals
• Introduction to nested VMX for KVM
• Introduction to debugging guest code in KVM

Details:

• Skill level: advanced
• Language: C, x86 assembly
• Mentor: Jan Kiszka <jan.kiszka@web.de>
• Suggested by: Jan Kiszka <jan.kiszka@web.de>

Libvirt projects

Introducing job control to the storage driver

Currently, libvirt support job cancellation and progress reporting on domains. That is, if there's a long running job on a domain, e.g. migration, libvirt reports how much data has already been transferred to the destination and how much still needs to be transferred. However, libvirt lacks such information reporting in storage area, to which libvirt developers refer to as the storage driver. The aim is to report progress on several storage tasks, like volume wiping, file allocation an others.

• Skill level: intermediate

More intelligent virsh auto-completion

Even though there's already some auto-completion in virsh, it is not enough. For better user experience, virsh should auto complete objects to virsh commands, e.g. "start <TAB><TAB>" lists not only options that the start command knows, but list of inactive domains as well. Moreover, the same applies to command options.

Some useful threads to read before trying this: [1] [2] [3] [4]

• Skill level: beginner

Introduce API to query IP addresses for given domain

One of the most desired APIs in libvirt that still hasn't been implemented. The aim is to get/guess list of IP addresses assigned to domain. There are several ways to get such list: asking guest agent, snooping for domain traffic, parsing dnsmasq lease file, etc.

• Skill level: beginner

Ability to run qemu-{system-}arm

Libvirt is nowadays tight to PCI bus based qemus: qemu-i386 and qemu-x86_64. However, with recent development of ARM architecture, as ARM based devices become more and more popular, the voice calling for ARM support in libvirt is getting stronger. The libvirt's assumption every domain has at least one PCI bus needs to be dropped and code adapted accordingly.

• Skill level: advanced

Libvirt Wireshark dissector

Libvirt uses RPC system for communication between clients and server. It would be nice, if a developer can look at decoded RPC messages in Wireshark. That is, leanr Wireshark to understand our RPC messages, decode each field and create a tree of them. However, each new API introduces some new constants, so the dissector should be generated.

• Skill level: advanced
• Language: C, perl

Links:

• http://libvirt.org/
• http://wiki.libvirt.org/page/Main_Page
• http://www.ibm.com/developerworks/linux/library/l-libvirt/index.html?ca=drs-
• https://www.berrange.com/topics/libvirt/
• https://www.redhat.com/archives/libvir-list/

Details:

• Component: libvirt
• Skill level: (see description to each item)
• Language: C
• Mentor: Michal Privoznik <mprivozn@redhat.com>, mprivozn on IRC (#virt OFTC)
• Suggested by: Michal Privoznik <mprivozn@redhat.com>

Add rename APIs for all objects

Currently libvirt has no rename API for any of the objects. For inactive objects, one has to use the combination of vir*Undefine, "change the XML", and "vir*Define" to achieve the renaming goal, which is not straightforward, and has potential failure on the half way. For active objects, there is no way for renaming. This project is to add rename APIs for all objects, including domain, snapshot, network, interface, nwfilter, secret, storage pool, and storage volume. Support to rename inactive objects is a good start, and support for active objects should be finished as much as possible (at least for hypervisor drivers like ESX and VirtualBox, which might already support the renaming natively).

• Skill level: beginner
• Language: C
• Mentor: Osier Yang <jyang@redhat.com || agedosier@gmail.com>, osier on IRC (#virt OFTC)

Project idea template

=== TITLE ===
 
 '''Summary:''' Short description of the project
 
 Detailed description of the project.
 
 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites
 
 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

Information for mentors

Mentors are responsible for keeping in touch with their student and assessing the student's progress. GSoC has a mid-term evaluation and a final evaluation where both the mentor and student assess each other.

The mentor typically gives advice, reviews the student's code, and has regular communication with the student to ensure progress is being made.

Being a mentor is a significant time commitment, plan for 5 hours per week. Make sure you can make this commitment because backing out during the summer will affect the student's experience.

The mentor chooses their student by reviewing student application forms and conducting IRC interviews with candidates. Depending on the number of candidates, this can be time-consuming in itself. Choosing the right student is critical so that both the mentor and the student can have a successful experience.