Revision as of 15:08, 6 February 2017

Introduction

QEMU is participating in Outreachy 2017 May-August. This page contains our ideas list and information for applicants and mentors.

How to apply

Read the Outreachy website first
Choose a project idea from the list below. You should have the necessary technical skills for the idea you have chosen.
Contact the mentor for your project idea to introduce yourself and discuss how you want to tackle the project.
Choose a small task from the BiteSizedTasks page and submit a patch contribution. See Contribute/SubmitAPatch for guidelines on patch submission.

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 audio backend

Summary: Rework QEMU audio backend

The audio backend facilitates audio playback and capture using host audio APIs (CoreAudio, PulseAudio, DirectSound, etc). It is used by emulated soundcards and may need to convert between the audio format supported by the emulated soundcard and the format supported by the physical soundcard. This area of the codebase has been stable for a long time but is now due some significant improvements.

The goal of this summer project is to improve the audio/ backend. The preliminary task is to rebase and merge (some or all) of the GSOC "audio 5.1 patches 00/51" series which modernizes the audio backend codebase.

Then, add a generic GStreamer audio backend. GStreamer is an open source multimedia framework that is cross-platform and already supports a lot of the functionality that is implemented in QEMU's audio backend.

Finally, try to replace as much of audio/ by custom gstreamer pipelines. This would be a major simplification that reduces the code size significantly, making QEMU's audio backend smaller and easier to maintain.

Links:

Details:

Skill level: intermediate or advanced
Language: C
Mentors: marcandre.lureau@redhat.com, kraxel@redhat.com
Contact: past gsoc student "Kővágó Zoltán" <dirty.ice.hu@gmail.com>
Suggested by: marcandre.lureau@redhat.com

Disk Backup Tool

Summary: Write a tool that performs both full and incremental disk backups

QEMU has added command primitives that can be combined to perform both full and incremental disk backups while the virtual machine is running. A full backup copies the entire contents of the disk. An incremental backup copies only regions that have been modified. Orchestrating a multi-disk backup to local or remote storage is non-trivial and there is no example code showing how to do it from start to finish.

It would be helpful to have a "reference implementation" that performs backups using QEMU's QMP commands. Backup software and management stack developers wishing to add QEMU backup support could look at this tool's code as an example. Users who run QEMU directly could us this tool as their backup software.

You need to be able to read C since that's what most of QEMU is written in. This project will expose you to backup and data recovery, as well as developing command-line tools in Python.

See the links to familiarize yourself with disk image files, backups, and snapshots.

Links:

Details:

Skill level: intermediate
Language: Python
Mentors: John Snow <jsnow@redhat.com> (jsnow on IRC), Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)

Moving I/O throttling and write notifiers into block filter drivers

Summary: Refactor the block layer so that I/O throttling and write notifiers are implemented as block filter drivers instead of being hardcoded into the core code

QEMU's block layer handles I/O to disk image files and now supports flexible configuration through a "BlockDriverState graph". Block drivers can be inserted or removed from the graph to modify how I/O requests are processed.

Block drivers implement read and write functions (among other things). Typically they access a file or network storage but some block drivers perform other jobs like data encryption. These block drivers are called "filter" drivers because they process I/O requests but ultimately forward requests to the file format and protocol drivers in the leaf nodes of the graph.

I/O throttling (rate-limiting the guest's disk I/O) and write notifiers (used to implement backup) are currently hardcoded into the block layer's core code. The goal of this project is to extract this functionality into filter drivers that are inserted into the graph only when a feature is needed. This makes the block layer more modular and reuses the block driver abstraction that is already present.

This project will expose you to QEMU's block layer. It requires refactoring existing code for which there is already some test coverage to aid you.

Links:

Details:

Skill level: intermediate
Language: C
Mentor: Kevin Wolf <kwolf@redhat.com> (kwolf on IRC), Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC), Alberto Garcia (berto on IRC)

PCI Express to PCI bridge

Summary: Code an emulated PCIe-to-PCI bridge for QEMU PCI Express machines

Modern Virtual Machines and their devices are PCI Express, however a means of supporting existing PCI and PCI-X deployment is required. Some use cases may need using legacy PCI devices that plug into platforms that exclusively support PCI and PCI-X system slots.

QEMU already has a solution, the i82801b11 DMI-to-PCI Bridge Emulation. However, the device has some disadvantages: it cannot be used by ARM guests and it is part of the Root Complex, so it can't be hot-plugged.

The goal of this summer project is to code a generic PCIe-PCI bridge. The bridge should be hot-pluggable into PCI Express Root Ports and be usable across various architectures and Guest Operating Systems.

Once the bridge is merged upstream, the PCI/PCI Express infrastructure will be ported to the QOM model to conform with QEMU standards, all that as the time permits.

Links:

Details:

Skill level: intermediate
Language: C
Mentor: marcel@redhat.com, marcel_a on IRC
Suggested by: Marcel Apfelbaum <marcel@redhat.com>

Add a Hypervisor.framework accelerator

Summary: Add x86 virtualization support on macOS using Hypervisor.framework

QEMU does not yet take advantage of Hypervisor.framework, the API for hypervisors on macOS. Currently one must use the slower TCG just-in-time compiler or the Intel HAXM accelerator module that relies on a third-party driver.

Hypervisor.framework was added to macOS in Yosemite (10.10). It exposes the Intel VMX CPU feature for running guest code safely at native speed. The main difference to the KVM or HAXM APIs is that the Hypervisor.framework user must implement instruction emulation to handle instructions that vmexit due to I/O accesses. Most of the code will be related to this emulator.

QEMU would be able to run x86 virtual machines with much better performance and without relying on third-party drivers thanks to Hypervisor.framework. This will make QEMU more useful on macOS and encourage more contributions from developers on that platform.

This project is an advanced project. You should be familiar with the concept of an emulator. Luckily there is the Linux KVM code as well as other code that implements VMX or Hypervisor.framework to use for inspiration. You will learn about writing the most core part of a hypervisor.

There is an existing QEMU-based Hypervisor.framework implementation in Veertu's hypervisor. This can serve as a reference and one way to approach the project is to take that code and get it merged into QEMU after necessary changes have been made.

Links:

Details:

Skill level: advanced
Language: C
Mentor: Alexander Graf <agraf@suse.de>

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.

@@ Line 24: / Line 24: @@
 {{:Internships/ProjectIdeas/DiskBackupTool}}
 {{:Internships/ProjectIdeas/BlockFilterRefactoring}}
+{{:Internships/ProjectIdeas/PCIe-PCI-Bridge}}
+{{:Internships/ProjectIdeas/HypervisorFramework}}
 == Project idea template ==