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:
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:
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:
Note: Submitting a patch and having it merged by QEMU or KVM increases your chances of being accepted.
This is the listing of suggested project ideas. Students are free to suggest their own projects, too.
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.
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.
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
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:
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.
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:
Medium priority tasks:
Useful features which can be added:
For background information on MTP, see http://en.wikipedia.org/wiki/Media_Transfer_Protocol.
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.
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.
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.
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.
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.
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.
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.
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.
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).
=== 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
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.