Introduction

QEMU is participating in Outreachy 2016 December-March. This page contains our ideas list and information for applicants and mentors.

Find Us

IRC: #qemu-outreachy on irc.oftc.net

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

Stefan Hajnoczi (stefanha on IRC)

Project Ideas

This is the listing of suggested project ideas.

QEMU projects

Reorganizing the QEMU documentation

Summary: Produce beautiful user and developer documentation for QEMU

QEMU's documentation currently consists of:

a manual written in the Texinfo language, whose source code is in part embedded in QEMU's program source code
several files written as markdown or text documents, stored in the docs/ folder. These include user documentation, developer documentation, and hardware specifications.
automatically generated documentation for the QMP protocol (in progress)

This project will look into the following tasks:

reorganizing the Texinfo documentation and extracting its contents to more easily editable markdown or reStructuredText files. pandoc can be used to convert md and rst back to Texinfo until the next steps are performed (pandoc can read rst and md, and it can write all of rst/md/Texinfo).
At this point, the bulk of the Texinfo documentation is already built from files residing in docs/.
converting the QMP protocol documentation generator to emit reStructuredText instead of Texinfo.
incorporating the contents of the docs/ folder into three manuals (user, developer, hardware).
using sphinx to build beautiful documentation directly from markdown or reStructuredText.
automating the publishing of this documentation on readthedocs.org.

Links:

Details:

Skill level: beginner-medium
Languages: Makefile, Python, Perl
Mentor: Paolo Bonzini <pbonzini@redhat.com> (bonzini on IRC)

qtest-os: a mini operating system written in Python

Summary: Write a Python library to interact with QEMU's qtest, and then as much as possible of a "mini-OS" written in Python

QEMU uses "qtest" as a mechanism for tests to interact with devices. qtest unit tests are currently written in C, using the GTest framework from glib and glue libraries called "libqtest" and "libqos". libqtest implements the qtest socket protocol, while libqos provides utility functions to deal with e.g. guest memory allocation and PCI devices. However, the functionality of libqos is limited, and using a high-level language like Python will make it easier to prototype and build more complex functionality in libqos.

This project will investigate using qtest from Python, including:

writing a Python library with the same functionality as libqtest
converting some of the existing tests from C to Python
extending qtest with a driver model ("qtest-os").

The last bullet splits a unit test in three parts: a description of QEMU's supported machine types, a set of drivers, and the unit test code proper. For example, given:

a SCSI unit test
a description of the machine type X saying that X a PCI bus
a driver for X's PCI host bridge
a driver for virtio-scsi

qtest would infer that the unit test can run by starting X with a virtio-scsi device.

Links:

An old prototype of a Python qtest library

Details:

Skill level: medium
Language: Python
Mentor: Paolo Bonzini <pbonzini@redhat.com> (bonzini on IRC)

VIRTIO 1.0 support in libqos

Summary: Add support for the latest VIRTIO paravirtualized device standard to the libqos test framework.

The VIRTIO 1.0 specification defines a family of paravirtualized devices, including virtio-net and virtio-blk, which are commonly used in QEMU guests. Paravirtualized devices are "hardware" interfaces designed specifically for emulation or virtualization.

QEMU has a low-level device test suite that uses a framework called libqos for common functionality like PCI and VIRTIO device access. These tests can exercise hardware registers to verify that emulated devices are implemented correctly by QEMU.

Currently libqos only supports legacy VIRTIO devices. The recent VIRTIO 1.0 standard introduces more flexible and performant memory layouts and hardware register interfaces.

The goal of this project is to add VIRTIO 1.0 support to libqos alongside the existing legacy VIRTIO support. This way both VIRTIO 1.0 and legacy code paths can be tested. If you complete this project early there are plenty of related tasks that you could tackle with the VIRTIO knowledge you will gain!

This project is suitable for candidates with an interest in device driver programming and hardware interfaces. You must be fluent in C programming.

Links:

Details:

Skill level: intermediate
Language: C
Mentor: Stefan Hajnoczi <stefanha@gmail.com> ("stefanha" on IRC)

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 candidate and assessing the candidate's progress.

The mentor typically gives advice, reviews the candidate's code, and has regular communication with the candidate 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 candidate's experience.

The mentor chooses their candidate by reviewing candidate application forms, giving out bite-sized tasks so applicants can submit a patch upstream, and conducting IRC interviews with candidates. Depending on the number of candidates, this can be time-consuming in itself. Choosing the right candidate is critical so that both the mentor and the candidate can have a successful experience.