Outreachy 2016 DecemberMarch

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

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:

• libqos virtio.h
• virtio-blk test using libqos
• VIRTIO 1.0 specification
• VIRTIO 1.0 overview (pdf)
• Presentation on latest VIRTIO status from KVM Forum 2016

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.