Google Summer of Code 2012

Introduction

As we did last year, QEMU is going to apply as a mentoring organization for Google Summer of Code 2012. This page contains our ideas list and some additional 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 (pending OK from libvirt people)

Organization

Any Question, request or problem regarding QEMU in GSoC, please contact the following people.

• Stefan Hajnoczi
• Luiz Capitulino
• Anthony Liguori

Find Us

• IRC (devel): #qemu on irc.oftc.net
• IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
• Mailing list: http://lists.nongnu.org/mailman/listinfo/qemu-devel

GSoC important pages

• FAQ
• Program Timeline
• Melange User Guide
• Advice for Mentors

Information for students

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 possible open source contributions)
• Why QEMU and why this project
• A detailed description of the approach the student will take

Please get in touch 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.

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

Projects Ideas

This is the listing of suggested project ideas. It might be useful to check last year's page. Also note that students are free to suggest their own projects.

== 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:'''
 * Component: QEMU or KVM or libvirt
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

git style front-end to QEMU

Summary: Provide a git like front-end for QEMU that allows for enumerating running instances and manipulating them from a command line.

Starting in the 1.0 release, we freed up the qemu executable name in order to allow a script to be introduced that would provide an easier to use scripting interface to QEMU. It would provide a series of sub commands like list, create, shutdown, etc. that would provide an alternative command line front-end to QEMU that the qemu-system executables.

Links:

• git user manual

Details:

• Component: QEMU
• Skill level: beginner
• Language: Python
• Mentor: Anthony Liguori <aliguori@us.ibm.com> (IRC: aliguori)
• Suggested by: Anthony Liguori

Finish OS X Virtualization Support

Summary: Finish up the last remaining pieces to enable running Mac OS X guests on Linux on Mac hardware

There are a few remaining pieces of work to allow virtualizing OS X guests in KVM. A few devices still need to be up-streamed. Testing needs to be done, and likely some new code will have to be written to fix certain bugs. The last time anyone was successful in running OS X in KVM was OS X 10.4. Support for newer versions would be required. The most recently updated patches that I know of would be in the OpenSUSE src rpm for the kvm package.

Links:

• most recent howto

Details:

• Component: QEMU/KVM
• Skill level: intermediate/advanced
• Language: C
• Mentor: Brian Jackson (Iggy), Alexander Graf
• Suggested by: Brian Jackson (Iggy)

In-process NBD server

Summary: Integrate qemu-nbd server functionality into qemu so disk images can be accessed remotely while the VM is running

The qemu-nbd utility is a stand-alone Network Block Device server which exports disk images (qcow2, qed, vmdk, etc). Linux has an NBD driver, this makes it possible to attach NBD devices like iSCSI or ATA-over-Ethernet volumes and operate on them like local block devices using mkfs, mount, and other common tools.

It is not safe to run qemu-nbd while the VM is running because the disk image could be corrupted by simultaneous updates or read access could give inconsistent results. The goal of this project is to make the qemu-nbd functionality available for a running VM by integrating it into qemu proper.

New QEMU monitor commands must be added to allow disk images to be exported from inside qemu while the VM is running. For safety the in-process NBD server would only allow read access. It should be possible to export not just top-level image files but also backing files.

This new feature will enable online backup, data migration, and other interesting scenarios.

Links:

• http://en.wikipedia.org/wiki/Network_block_device
• http://blog.vmsplice.net/2011/02/how-to-access-virtual-machine-image.html

Details:

• Component: QEMU
• Skill level: intermediate
• Language: C
• Mentor: Stefan Hajnoczi <stefanha@gmail.com>, 'stefanha' on IRC
• Suggested by: Stefan Hajnoczi

Partial device emulation in KVM

Summary: Add support for and benchmark partial device emulation in KVM

When using KVM, almost all device emulation is done in user space (QEMU). While this is really nice from an architecture point of view, it's not the greatest thing when it comes to latencies. Some devices like IDE, VGA, HPET have very hot path registers that can be easily emulated in the kernel (KVM), with all heavier operations going to user space.

This project is about prototyping such partial device emulation to see if it actually does give us speedups. If you manage to show great performance improvements with it, we would then work on finding clean solutions to integrate this upstream and also push it upstream.

With a bit of luck, we might end up getting significant speedups to KVM!

Mid-term goal: Implement prototype for one of the 3 mentioned devices, do benchmarks

Final goal: If the prototype was successful, work on upstreaming it, if not, pick another device and implement a prototype for that

Links:

• IDE specs
• HPET spec
• VGA spec

Details:

• Component: QEMU, KVM
• Skill level: intermediate/advanced
• Language: C
• Mentor: Alexander Graf
• Suggested by: Alexander Graf

IA64 emulation

Summary: Add support for IA64 system emulation in QEMU

The KVM project had a working IA64 port that was able to run a virtualized system with KVM and QEMU as it was back in those times. If we take the hardware emulation from that and add CPU emulation to the mix, we should get a workable solution for IA64 emulation.

Because most applicants won't own their own IA64 box, I will provide access to one so that we can rule out the CPU emulation bits of the equation and focus on getting the device model working well enough to at least run the firmware as a first target milestone. CPU emulation comes second.

Mid-term goal: Make (current) QEMU work on IA64 with KVM

Final goal: Implement CPU emulation to a point where TianoCore works

Links:

• Last year's attempt at IA64 emulation
• KVM help text in the kernel for IA64
• Talk on IA64 KVM
• SKI - a working IA64 emulator
• TianoCore - the open source EFI firmware
• Xen IA64 ML
• Talk on IA64 Xen

Details:

• Component: QEMU
• Skill level: intermediate/advanced
• Language: C, IA64 asm
• Mentor: Alexander Graf, Jakub Jermar
• Suggested by: Jakub Jermar

Live migration with new GET_DIRTY_LOG

Summary: Improve QEMU's live migration with a new GET_DIRTY_LOG which makes dirty page logging more flexible.

Dirty page logging is a technique used for tracking modified guest memory during live migration or VGA emulation. KVM has an API, called GET_DIRTY_LOG, which can be used for this: the caller gets the logged information in a bitmap that indicates which pages have become dirty since the last call.

One problem we are facing about this is that this API needs to hold a lock, which is needed to do some mmu related work, too long if a lot of guest pages are dirty and this may cause noticeable latency in the guest.

A new API being proposed now can limit the range of memory from which we take the log information and thus makes it possible to control the latency by not trying to handle too many pages at once.

Note: this is not a simple task that you can do by simply following my instructions. Actually I am not 100 percent sure whether this approach will work well because I have not used the new API yet. So applicants need to understand QEMU's live migration correctly by themselves and think whether this proposal can be achieved in 12 weeks before applying for this.

I am offline from March 23 to March 28.

Links:

• dirty-log-perf test in kvm-unit-tests
• GET_DIRTY_LOG development using dirty-log-perf
• Attempt to implement new GET_DIRTY_LOG API
• Next generation kvm api being proposed now

Details:

• Component: KVM, kvm-unit-tests, QEMU
• Skill level: intermediate/advanced
• Language: C, C++
• Mentor: Takuya Yoshikawa <takuya.yoshikawa__AT__gmail.com>
• Suggested by: Takuya Yoshikawa

Tracepoint support for the gdbstub

Summary: Implement basic gdb tracepoint support in the gdbstub for x86 targets.

Recent gdb versions allow to define ad-hoc tracepoints that are able to record memory content or register states whenever the target code hits them. This is supposed to happen non-intrusively, while the target is executing (almost) as normal. QEMU could serve as a nice backend for gdb when it comes to using such dynamic tracepoints for (guest) kernel debugging. In contrast to approaches like kgtp running inside the guest kernel, QEMU is able to perform this in hypervisor context, at most requiring to insert breakpoints into guest visible memory.

In this project, the QEMU gdbstub shall be extended with support for tracepoints. Architecture specific parts shall at least support x86 guests. Tracepoints shall be usable both in emulation and KVM mode. Extending the KVM kernel services to accelerate tracepoints is not required in this first step.

Links:

• gdb documentation
• gdb remote protocol

Details:

• Component: QEMU
• Skill level: intermediate
• Language: C
• Mentor: Jan Kiszka <jan.kiszka@web.de>
• Suggested by: Jan Kiszka <jan.kiszka@web.de>

Rework user space TCP/IP stack

Summary: Modernize and document QEMU's user space TCP/IP stack Slirp.

One of the most disliked QEMU subsystems is its user space networking stack. It allows to create zero-config unprivileged guest networks that are automatically confined to the privileges of the user who starts the virtual machine.

The stack is derived from the Slirp project but has been extended and fixed in various ways over the years. Still, it doesn't comply to QEMU's coding style and comes with various code obfuscations, mostly once introduced to keep the delta to the original project small. But as the source project is dead by now and QEMU's version evolved significantly, a rework of the stack is appropriate and more than overdue.

The goal of this project is to perform a careful step-wise rework of QEMU's Slirp. It shall be backed by regression tests and maintain the bisectability for each change, i.e. each step can be built and executed, and none breaks available tests. The following aspects shall be addressed in this project:

• create regression test suite, consisting e.g. of unit tests and KVM autotest extensions
• identify and remove dead code /wrt QEMU usage
• refactor and document packet queues
• refactor timer handling, converting it from polling to a truly time-driven scheme
• adjust source files to QEMU coding style
• document basic principles and typical control flows of the Slirp stack

Links:

• Slirp subsystem in QEMU

Details:

• Component: QEMU
• Skill level: intermediate
• Language: C
• Mentor: Jan Kiszka <jan.kiszka@web.de>
• Suggested by: Jan Kiszka <jan.kiszka@web.de>

Add Macintosh to 68k system emulation

In order to support Macintosh system emulation, almost every device must be implemented on QEMU (SCSI, CUDA, ADB, Apple framebuffers). How they work can be investigated in Inside Macintosh documents and other emulators (MESS, BasiliskII, vMac).

• Skill level: high
• Languages: C, 68k assembler
• Mentor: Natalia Portillo
• Suggested by: Natalia Portillo

Boot Mac OS >= 8.5 on PowerPC system emulation

Most of Power Macintosh hardware is emulated, things need only to be cleaned and OpenBIOS enhanced to support loading Macintosh Toolbox from the "Mac OS ROM" file present in any Mac OS >= 8.5 system. Last year some progress was done to boot Mac OS X (powerpc) but a race condition was found on OpenBIOS implementation.

• Skill level: medium
• Languages: C, Forth
• Mentor: Natalia Portillo
• Suggested by: Natalia Portillo

BeBox system emulation

The BeBox system is just a CHRP compliant dual PowerPC 603 processor machine. Most of the devices are already emulated, only a couple need to be added. Original firmware can be reverse engineered as it is a very simple firmware (not OpenFirmware compliant).

• Skill level: medium
• Languages: C, maybe PowerPC assembler
• Mentor: Natalia Portillo
• Suggested by: Natalia Portillo

NeXT machines system emulation

NeXT machines are designed in a similar idea to 68k Macintosh ones. Documentation is almost not available. Original firmware MUST be used. MESS emulator project started a NeXT emulation but it is still work-in-progress so not much ideas can be taken from it. Last GSoC an emulation able to run up the firmware was implemented, this year will continue from it (next step, SCSI emulation).

• Skill level: high
• Languages: C, 68k assembler
• Mentor: Natalia Portillo
• Suggested by: Natalia Portillo

Upstream and clean-up of USB Video Class device emulation

On mid-2010 I implemented a webcam emulation (passthrough) using USB Video Class on the guest and Video4Linux on the host. The code was RFC to the mailing list and needs a couple of clean ups to be integrated mainstream. Once cleaned up, it needs to get implemented multiple resolution, image formats and isochronous transfers. Desirable is also adding support for Win32 (using WIA or VFW) and Mac OS X hosts.

• Skill level: medium
• Languages: C
• Mentor: Natalia Portillo
• Suggested by: Natalia Portillo

Implementation of FireWire OHCI

Implementing a FireWire OHCI emulation will allow us to passthrough FireWire devices (mass storage, tape devices, video devices, IPo1394), or to emulate that devices from different host devices.

FireWire extensively uses DMA and should be as easy to implement as USB protocol, without the issues of the bulk mode of USB protocol.

• Skill level: high
• Languages: C
• Mentor: Natalia Portillo
• Suggested by: Natalia Portillo