As we did last year, QEMU is going to apply as a mentoring organization for Google Summer of Code 2011. 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:
Any Question, request or problem regarding QEMU on GSoC 2011, please contact one of the following people.
We require students to provide (at least) the following information in their applications:
VERY IMPORTANT: 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. It might be useful to check last year's page. Also note that students are free to suggest their own projects.
Summary: Design and implement an in-place disk image converter that safely and efficiently changes between the QCOW2 and QED image formats.
QEMU supports several disk image formats that make it possible to manage and share virtual machine disk images as files. The well known formats include qcow2 (QEMU) and vmdk (VMware), and the QEMU Enhanced Disk (QED) format has pushed new levels of performance.
In order for users to go between formats, the qemu-img convert command reads a disk image in one format and outputs it in another format. This has two limitations:
The aim is to design a safe in-place converter to change from QCOW2 to QED (and vice versa) without copying image data. This will require understanding the QCOW2 and QED image formats and how they organize image data. You will need to carefully design the process so image data is never at risk in the event of a crash during conversion. Finally, you will be responsible for adding tests that defend this feature to the qemu-iotests suite.
Links:
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 for this project idea.
Summary: Add support for the latest versions of popular image formats.
There are a number of disk image formats in common use today. The qemu-img tool already supports the popular image formats. Some formats have evolved since their original support was added and new files cannot be accessed with qemu-img.
The aim is to address the lag in image format support by understanding the latest formats and implementing their new layouts in QEMU. This will enable qemu-img, qemu-io, and qemu-nbd to operate on an even wider range of disk images.
Links:
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 for this project idea.
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. See gdb documentation and specifically the gdb remote protocol for further details.
There exists a good foundation for EHCI support in out-of-tree repository. But it hasn't been proposed for merge yet due to a few open issues. The list below reflects potential sub-tasks but it's not necessarily up-to-date with latest development:
The primary goal of this task is to fix the most annoying issues of the EHCI emulation and prepare the result of upstream merge.
There are still a few rough edges in QEMU's USB support beyond the EHCI topic:
The task consists of identifying open issues and use cases by testing them against various guest systems, then fixing the deficits, and proposing the result in form of patch series for upstream merge.
The Android Emulator is based on ancient QEMU. To kick off its upstream integration, the existing code shall be analyzed and core elements of the emulated reference platform shall be ported to current QEMU. The goal is to get some Android image booting, bringing it into a usable state so that simple applications can be tested.
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).
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.
More x86 guests have native drivers for that card than for Cirrus GD5446. It was also used for a lot of non-x86 machines (like IBM workstations and servers).
ARM system emulation should include Acorn Archimedes system emulation. Work-In-Progress was done against 0.9.0 tree. Now with Risc OS open sourced things could be easier. Most problems seems to be rarely used opcodes and 26-bit modes.
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).
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.
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.
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.
USB 3.0 gives better support for virtualization, and also unlike EHCI does not request the presence of previous generation controllers (EHCI, OHCI, UHCI) for handling previous generation devices (USB 2.0, USB 1.x).
This requires also taking in account Gerd patches for multiple speeds support on existing USB devices.
Summary: Create a virtagent compatible guest agent for Windows operating systems.
Virtagent is a host/guest communication protocol that is designed to enable easier and more reliable guest management. An RPC channel is created over either a virtio-serial or isa-serial device. Various commands are implemented such as: shutdown, ping and file retrieval. Currently, only Linux guests are supported. In order to make virtagent a more universal management interface, it should be supported on other operating systems (including Windows). This task can be broken down into the following activities:
Applicants will need to have experience with Windows system programming.
Summary: Port KVM code to Mac OS X to run hardware accelerated qemu on Mac OS X
KVM provides a pretty simple interface for userspace applications like qemu to run virtual machines. There's no reason (except for the license) it should be limited to Linux kernel code though. We could wrap the Linux KVM code around some helpers that provide Linux functionality on XNU - the Mac OS X kernel. That would enable qemu to run virtual machines on Mac OS X hosts.
Applicants will need to have understanding of the XNU kernel and a broad grasp of KVM's kernel interfaces.
Summary: Emulating the IA64 instruction set
Qemu implements all the of still-alive and soon-not-to-be-alive platforms out there, except for one! Itanium! We do have device emulation support for it in the qemu-kvm fork. There is existing firmware out there that even works with KVM on IA64. So all that's necessary to get people who don't have IA64 machines at home the fun of playing with it is CPU emulation code.
The project would start by getting an ia64-linux-user target rolling that can emulate IA64 Linux applications on other Linux systems. This will probably be enough of a scope for this GSoC.