Outreachy 2020 DecemberMarch

Introduction

QEMU is applying to participate in Outreachy 2020 December-March.

This page contains information for mentors since we are currently in the organization application phase. Final information for internship applicants will be published if QEMU is accepted.

Key Dates

From the outreachy website:

• Aug. 24, 2020 at 4pm UTC - Initial applications open
• Sept. 14, 2020 at 4pm UTC - Initial application deadline
• Oct. 1, 2020 - Project list finalized
• Oct. 1, 2020 to Oct. 31, 2020 - Contribute to projects
• Oct. 31, 2020 at 4pm UTC - Final application deadline
• Nov. 23, 2020 at 4pm UTC - Accepted interns announced
• Dec. 1, 2020 to March 2, 2021 - Internship period

How to apply

1. Read the Outreachy website first
2. Choose a project idea and follow the steps on QEMU's Outreachy page.
3. Contact the mentor for your project idea to introduce yourself and discuss how you want to tackle the project.
4. Choose a small task from the BiteSizedTasks page and submit a patch contribution. See Contribute/SubmitAPatch for guidelines on patch submission.

Project ideas

ioregionfd - new device access dispatch mechanism

Summary: Implement a mechanism in the Linux kvm.ko kernel module to dispatch device accesses directly to a process or thread without jumping through the QEMU vCPU thread.

Virtual devices such as graphics cards and network cards can be emulated in dedicated tasks (processes or threads) instead of running in QEMU's vCPU or main loop threads. Dedicated tasks have security and performance advantages because they are isolated and can run on dedicated physical CPUs.

Some devices cannot be emulated efficiently yet because there is no way for the Linux kvm.ko kernel module to dispatch device accesses directly to the device emulation task. Today it is necessary to jump through the QEMU vCPU thread first and then forward the access to the dedicated task, which is slow. A few existing devices use the ioeventfd mechanism to avoid this but it only works for "doorbell" writes, not for read accesses or non-doorbell writes. This project is about implementing a general solution called ioregionfd.

Here is how read accesses and non-doorbell writes are dispatched today:

kvm.ko  <---ioctl(KVM_RUN)---> QEMU <---messages---> device task

ioregionfd eliminates the extra step through QEMU like this:

kvm.ko  <---ioregionfd---> device task

This project consists of implementing the KVM_SET_IOREGIONFD ioctl in the Linux kvm.ko kernel module and writing test cases. As a stretch goal you could update QEMU's emulated NVMe device to run in a dedicated QEMU IOThread using ioregionfd.

Please take a look at the ioregionfd API design discussion link below to understand the new ioctl proposal.

This project idea is suitable if you would like to gain Linux kernel programming and virtualization/emulation experience. No prior kernel programming experience is required but you must be able to write production-quality C (understand pointers, dynamic memory allocation, and error-handling in C).

Links:

• ioregionfd API design discussion
• kvm.ko KVM_IOEVENTFD ioctl documentation
• ioeventfd implementation

Details:

• Skill level: advanced
• Language: C
• Mentor: Stefan Hajnoczi <stefanha@redhat.com>

vhost-user-scsi device server in Rust

Summary: Implement a vhost-user-scsi device server in Rust

The vhost-user protocol allows driving a virtio process from a separate process. This is better from a security perspective, as it allows to implement a better privilege separation policy, but also makes possible to implement the device personality using a foreign programming language (QEMU is mainly written in C) and to experiment with optimization features that would be hard to deploy inside QEMU itself.

There are already a number of crates in the rust-vmm umbrella project that provide a framework for writing vhost-user device servers in Rust, and some device servers implementations such as vhost-user-blk, vhost-user-net and vhost-user-fs.

This project consists in writing a vhost-user-scsi device server in Rust that's able to serve multiple virtual LUNs, each one backed by a different disk image or iSCSI target. If time allows, benchmarks should also be provided comparing its performance against the integrated virtio-scsi implementation.

Links:

• Vhost-user protocol documentation
• "Why QEMU should move from C to Rust"
• vhost crate in Rust-VMM, which includes support for vhost-user
• vhost-user-fs device server in Rust

Details:

• Skill level: Intermediate
• Language: Rust
• Mentor: Sergio Lopez <slp@redhat.com>

How to add a project idea

1. Create a new wiki page under "Internships/ProjectIdeas/YourIdea" and follow #Project idea template.
2. Add a link from this page like this: {{:Internships/ProjectIdeas/YourIdea}}

Example idea from a previous year: Internships/ProjectIdeas/I2CPassthrough

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

Find Us

• IRC: #qemu-gsoc on irc.oftc.net (this channel is shared with Google Summer of Code internships)

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

• Stefan Hajnoczi (stefanha on IRC)