Google Summer of Code 2010

From QEMU

Introduction

QEMU has been accepted as a mentoring organization for Google Summer of Code 2010! You can visit our organization profile here.

Organization

Any problem, question or request regarding QEMU projects on GSoC 2010, please contact one of the following people.

Find Us

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

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

GSoC important pages

Projects Ideas

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

Convert Monitor commands to the QObject API

In order to support different types of output (eg. user Monitor and a machine protocol), we have introduced an object layer to QEMU. Every monitor command should be converted to use the API provided by that layer (called the QObject API), currently we have several commands still to be converted.

Improve/Simplify the QObject API

In order to support different types of output (eg. user Monitor and a machine protocol), we have introduced an object layer to QEMU. This object layer has an API, called the QObject API. Currently it is too low-level and doesn't provide good debugging functionality.

Improve error handling in Monitor handlers

QEMU handlers implement Monitor commands. Several of those handlers use functions which print data to a fixed location (say standard error) which is wrong, as the Monitor output maybe graphical for example. Some functions don't do any error check at all, others will just abort(). Additionally, most of them have to be converted to the QError API.

Add AHCI emulation to QEMU

Newer Windows versions run in Qemu only with IDE emulation which is very slow. Writing virtio drivers is also difficult because drivers for those Windows versions needs to be signed. An alternative is to implement a device emulation which fits better to virtualization needs. AHCI has one of those device interfaces and is currently not emulated by Qemu. Goal of this project is to implement an AHCI emulation for Qemu.

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).

Mac guest machine support (x86)

In order to boot Mac OS X for Intel architectures an ICH-7 chipset needs to be emulated. The biggest missing part is SATA emulation (AHCI).

Mac-on-Linux guest machine support (ppc)

The Mac-on-Linux project has a working paravirtual device collection, firmware and bootloader to make Mac OS X work inside Mac-on-Linux. With this device set ported to Qemu, we could obsolete the Mac-on-Linux project as is and use TCG and KVM as backends.

G3/G4 KVM host support

I'm not sure this is the right place to put this. If not, please mark it as invalid.

KVM for PowerPC supports G5 hosts today. To fully deprecate the Mac-on-Linux kernel module, we'd need to get PPC32 host support too.

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.

Add a S3 Trio or S3 Virge

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).

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

Enhance, update and integrate Acorn Archimedes system emulation

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.

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).

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.

Shared memory transport between guest(s) and host

The goal of this project is create a shared memory transport between guest VMs (and the host) that is exposed up to the user-level to allow for application-specific zero-copy communication. Synchronization mechanisms will be provided via eventfd notifications (and using ioeventfds in the KVM case). This requires the creation of a Qemu PCI device that can map a POSIX memory object from the host into the guest. To support multiple guests, a shared memory server will pass eventfd and shared memory file descriptors to each guest using SCM_RIGHTS.

  • Skill level: medium
  • Languages: C
  • Mentor: Avi Kivity
  • Suggested by: Cam Macdonell

Pass through file systems (9p, CIFS)

The goal of this project would be to produce a seamless user experience sharing a portion of the host file system with the guest. This could focus on a number of technologies. We could provide better support within QEMU to expose a Samba-based CIFS mount to a guest. This would involve modifications to Samba to allow all of the port traffic to be tunneled over a unix domain socket so that TCP ports on the host were not needed. It would also involve a small bit of Windows code to automatically use network shares on a special interface. Finally, it would involve adding code to QEMU to plumb all of this together.

Another possibility is to focus on taking the recent virtio-9p support and providing a better user experience with it. This would involve auto mount code within the guest to discover and automatically configure special types of virtio-9p mounts.

  • Skill level: medium
  • Languages: C
  • Mentor: Anthony Liguori
  • Suggested by: Cam Macdonell

Add more sophisticated encodings to VNC server

QEMU's built-in VNC server only supports the Hextile encoding. Hextile only uses tile-based compression. Other encodings are more popular such as Tight and ZRLE that use zlib-based compression. These encodings significantly reduce the bandwidth required by VNC. This project would start by implementing support for Tight or ZRLE. Both encodings support a combination of tile-based compression and zlib-compression. Initially, one would implement zlib-compression only and compare the results to our Hextile implementation. Depending on progress, tile-based compression mechanisms (such as Tight's gradient algorithm) could be explored. At each stage, we expect that performance comparisons are done to determine the effectiveness of the additional algorithm. Additional compression mechanisms like Tight's JPEG encoding could also be evaluated.

Write a C QMP library based on QEMU JSON and QMP code

As of QEMU 0.12.0, we expose a new JSON based management interface called QMP. We would like to also ship a library for interacting with that interface as part of QEMU. This project would involve taking the JSON parsing and QObject code and separating it out into a shared library. It would also involve implementing a higher level API based on this code that exposes each of the QMP functions.

Add support for guest copy/paste

For QEMU 0.13.0, we will support a special communications channel between the host and guest based on virtio-serial. One goal of this channel is to implement features like transparent copy/paste support between the host and guest. This project would involve writing a daemon that runs in the guest that uses a well known virtio-serial port to implement a copy/paste proxy. It would also involve implementing host-side support in QEMU via the VNC server. Initially, the project would focus on a GTK-based implementation for Unix systems but depending on progress, it could also involve implementing a Windows copy/paste daemon.

Device state visualization

For debugging guest access to emulated hardware, it can be very useful to obtain the state of those devices. The idea is to make use of QEMU's infrastructure to freeze devices for snapshots/migrations, but write that snapshots in a human-readable form to the monitor interface. Besides plain dumping of known variables, there should also be a way to add pretty-printing for key information of individual devices, like translated flag bits, visualized queue content, etc.

  • Skill level: medium
  • Languages: C
  • Mentor: Jan Kiszka
  • Suggested by: Jan Kiszka

Upstreaming some of the Android emulator bits

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.

  • Skill level: medium..high
  • Languages: C
  • Mentor: Jan Kiszka
  • Suggested by: Jan Kiszka

Completing big real mode emulation

  • Skill level: high
  • Languages: C, x86 assembly
  • Mentor: Avi Kivity
  • Suggested by: Avi Kivity

IOMMU emulation

Modern computers come with an IOMMU, which assists in assigning host devices to virtualized guests. An emulated IOMMU, in conjunction with svm emulation or kvm's nested svm, can be used for assigning guest or even host devices to nested guests. This can improve performance and greatly aid with automated testing.

VNC server coroutine

Our builtin VNC server is implemented as a combination of a pure state machine to allow scalability. The VNC protocol is very complex though and this implementation is difficult to follow as a result. This project would convert to the existing server to be implemented as a cooperatively scheduled thread in the style of a coroutine. Time permitting, a pure coroutine implementation using ucontext could be implemented. Also, given sufficient progress, one could pursue running the VNC server thread in parallel with the QEMU IO thread in order to achieve better overall scalability.

Retrieved from "https://wiki.qemu.org/index.php?title=Google_Summer_of_Code_2010&oldid=5306"