Outreachy 2016 MayAugust

From QEMU

Introduction

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

Find Us

  • IRC: #qemu-outreachy on irc.oftc.net
  • IRC (development):
    • QEMU: #qemu on irc.oftc.net
    • KVM: #kvm on chat.freenode.net

Please contact the mentor for the project idea you are interested in. IRC is usually the quickest way to get an answer.

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

How to get familiar with our software

See what people are developing and talking about on the mailing lists:

Grab the source code or browse it:

Build QEMU and run it: QEMU on Linux Hosts

Project Ideas

This is the listing of suggested project ideas.

QEMU projects

AF_VSOCK packet capture in Linux and Wireshark

Summary: Develop a AF_VSOCK packet capture Linux device driver and Wireshark dissector

Wireshark and Linux's packet capture functionality support more than just Ethernet traffic dumping. USB device traffic and netlink software communication can also be captured.

The AF_VSOCK address family is currently not support by Wireshark because there is no Linux kernel device driver for packet capture. AF_VSOCK is the socket address family that is used by the virtio-vsock host/guest communication device that is currently in development. The aim of this project is to first implement a Linux device driver for AF_VSOCK packet capture and then a Wireshark dissector. Minor changes to tcpdump may be necessary too.

This will allow tcpdump and Wireshark to dump host/guest communication with virtio-vsock (and maybe also VMware VMSockets). Traffic capture is an essential debugging tool for network communication and has not been available to programs using AF_VSOCK.

This project is challenging because you need to work on multiple codebases. You must have experience with device driver development and network programming.

Links:

Details:

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

qemu-img fuzzing using afl-fuzz

Summary: Apply the afl-fuzz fuzz testing tool to qemu-img and submit patches fixing bugs discovered with afl-fuzz.

The qemu-img tool is used to convert between disk image file formats and inspect image files. It supports multiple file formats including qcow2, vmdk, vhdx, and parallels. Since this tool is often used on untrusted inputs (e.g. in a cloud or hosting environment where end-users can upload disk image files), it must not allow arbitrary code execution or other classes of security bugs.

afl-fuzz instruments the program to record codepaths taken for each input test file. This allows afl-fuzz to mutate inputs and choose the ones that explore new codepaths. The amount of prior knowledge that afl-fuzz needs about the input grammar is limited since it learns how inputs affect the codepath. This makes it possible to fuzz various disk image file formats without painstakingly writing grammars for each file format.

In Outreach Program for Women 2014, a qcow2-specific fuzzing tool was developed in Python and several bugs were discovered. This project aims to tackle the other file formats (especially vmdk, vhdx, and parallels).

This project is suitable for candidates interested in software security, software testing, compilers, and disk image file formats.

Links:

Details:

  • Skill level: intermediate
  • Language: C
  • Mentor: Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)
  • Suggested by: Stefan Hajnoczi

qemu-img new subcommand "dd"

Summary: Add "qemu-img dd" subcommand.

dd(1) is a convenient tool to work on binary files, while qemu-img(1) has the knowledge of many image formats (qcow2, vhdx, vdi, vmdk, etc.) and protocols (nfs, iscsi, gluster, ssh, etc.). If we put them together, we'll have the power of dd to work on various virtual images, or even pipe it through any host side utilities, such as grep(1), xxd(1) or xz(1). The idea is to implement a new subcommand in qemu-img, the tool provided by QEMU for manupulating virtual images. 

Currently qemu-img has following subcommands:

Command syntax:
 check [-q] [-f fmt] [--output=ofmt] [-r [leaks | all]] [-T src_cache] filename
 create [-q] [-f fmt] [-o options] filename [size]
 commit [-q] [-f fmt] [-t cache] filename
 compare [-f fmt] [-F fmt] [-T src_cache] [-p] [-q] [-s] filename1 filename2
 convert [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename
 info [-f fmt] [--output=ofmt] [--backing-chain] filename
 map [-f fmt] [--output=ofmt] filename
 snapshot [-q] [-l | -a snapshot | -c snapshot | -d snapshot] filename
 rebase [-q] [-f fmt] [-t cache] [-T src_cache] [-p] [-u] -b backing_file [-F backing_fmt] filename
 resize [-q] filename [+ | -]size
 amend [-q] [-f fmt] [-t cache] -o options filename

You will extend the subcommand set with the new "dd" command, in a syntax that is familiar to *nix "dd" users.

Note that we don't have to mirror the behavior of GNU coreutils' or BDS systems' dd(1), or try to support every operand found there. A subset of operands (and probably some qemu-img specific ones) as chosen by you will be implemented. It is also your responsibility to write documentation for the new command and options.

Links

Details:

  • Skill level: beginner
  • Language: C
  • Mentor: Fam Zheng <famz@redhat.com>, fam 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
  • using the existing Python bindings to ACPICA (the ACPI reference implementation) to write ACPI unit tests
  • 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:

Details:

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

Postcopy migration: Recovery from a broken network connection

Summary: Improve the postcopy migration mode so it can cope with a network failure during the migration.

Postcopy migration is a scheme that is good at live migrating large VMs that rapidly change memory, but if the network connection fails during the postcopy phase you're left with an inconsistent VM. I had some ideas how to fix this by putting both VMs into a paused state and then hunting for the missing pages (see the Links).

Links: https://www.mail-archive.com/qemu-devel@nongnu.org/msg344360.html

Details:

  • Skill level: medium/advanced
  • Language: C
  • Mentor Dave Gilbert <dgilbert@redhat.com> (davidgiluk on IRC)

Multi-threaded TCG Projects

Summary: The MTTCG Project is an ongoing project to convert the TCG engine from its current single threaded approach to something that will take advantage of all cores on a modern processor. With this conversion things that where true in the old world mat not be true now, especially on non-x86 backends.

Runtime memory ordering refers to the guarantees about ordering of load and store operations the processor makes to the program. On x86 (which is strongly ordered) all loads and stores appear sequentially consistent. On other architectures there are often specialised instructions, for example ARMv8 has LDAR (Load Acquire) and STLR (Store Release), which indicate what assumptions can be made.

A naive implementation of a solution would be to introduce new TCGOps to represent these barriers and emit explicit barriers on the backend when needed. A more complex solution could then merge barrier operations with the next load/store operation to generate more efficient generated code. It's expected that the pathalogical case would be supporting x86 guests on weak model backends as every load and store will need a full memory barrier. This may make MTTCG for x86 on ${OTHER ARCH} pointless.

Further Reading:

Requirements: Working on this will require the student to develop a good understanding of micro architectures and the ability to read architectural manuals to glean correct behaviour of operations. An understanding of compiler theory or previous knowledge of the TCG would also be beneficial to this work. Finally as the MTTCG code is not itself currently up-streamed a familiarity with GIT and being able to frequently re-base work on a moving target would be useful.

Details:

  • Skill level: advanced
  • Language: C
  • Mentor Alex Bennee <alex.bennee@linaro.org> (stsquad on IRC)

Event loop profiling tool

Summary: Develop a top(1)-like tool to monitor event loop dispatching

A running QEMU process can have a number of different types of threads. An I/O thread (either the main thread, or a custom iothread for dataplane devices) is a thread that runs an poll based event loop.

The event loop dispatches I/O events that come from user interface (e.g. monitor fd), guest OS (e.g. ioeventfd), or program's internal sources (e.g. bottom halves or timers). Their occupation of host CPU time is often very useful debug/diagnostic information. Ideally the profiling code in QEMU would be in a dedicated thread so it is still usable even when the event loops are stuck.

In this project you will develop a tool for QEMU that is like the top(1) utility for Linux, to monitor QEMU's event loops. As a prerequisite, you need to modify QEMU to expose necessary data that will be collected by the new tool to generate the profiling output.

You must be familiar with (n)curses library and multi-threaded programming. You can write the tool in either C or Python.

Links:

Details:

  • Skill level: advanced
  • Language: C, (optional) Python
  • Mentor: Fam Zheng <famz@redhat.com>, fam on IRC

Qemu usb-mtp emulation

Summary: Make usb-mtp a reliable host/guest file sharing medium

USB Media Transfer Protocol is a ubiquitous way of transfering digital media, especially with portable devices such as smartphones, tablets etc. It is an interesting approach because unlike other methods, the device exposing the feature has full control on file operations thereby ensuring data integrity.

Qemu can emulate a USB MTP server which can enable guests to have an easy way of sharing files with the host. All modern operating systems come with MTP clients to make this a plug and play experience.

This project aims to add missing features to Qemu's usb-mtp emulation and make it robust and stable for everyday use.

One of the most important missing features is write support i.e guests have read-only access to the MTP share. It's envisioned that that would be one of the main deliverables of this project. Adding write support involves propagating changes to existing and new MTP Objects back to the server. Write support also involves Quotas so that clients cannot indiscriminately write to the share and fill up the entire volume.

There are other potentially interesting features that can be added such as metadata support, PTP backwards compatibility (Mac OS ?) etc

As mentioned above, another important aspect of this project is to make the emulation stable. Currently, usb-mtp has been primarily tested with Linux guests. We should test other guest operating systems and fix issues as they come up.

Experience with USB, MTP, Virtual file systems, and upto some extent, the Qemu device layer will be helpful but not required. That said, this project is a good way for interested students to delve deeper into these areas.

Links:

Details:

  • Skill level: advanced
  • Language: C
  • Mentor: Bandan Das <bsd@redhat.com> (bsd on IRC)
  • Mentor: Gerd Hoffman <kraxel@redhat.com (kraxel on IRC)

Qemu AMD IO MMU emulation

Summary: Interrupt remapping/Improvements to Qemu AMD IO MMU emulation

The I/O Memory Management Unit (IO MMU) is a system function that translates addresses used in DMA transactions, protects memory from disallowed access by I/O devices, and remaps peripheral interrupts.

A project to add AMD IO MMU emulation to Qemu has been on going for a while. The aim of this project should be to get the current patches merged into Qemu (If they're not merged by then). In addition to that we should implement interrupt remapping for the user-space irqchip mode in a similar way to what is currently done with Intel VT-d. The two above should be the main aims of the project but we should also experiment with caching root page table pointer, polishing event logging abilities of IO MMU where as much information as possible relating to an event should be encoded into the event log data, some events should be written to the hardware event reporting registers, some events are not reported e.t.c., implement interrupts related to r/w1c IO MMU control register bits starting from modifying ACPI tables if necessary. This project should also put some focus on some bugs in address translation whereby IO MMU sometimes receives host physical addresses instead of guest physical address from Qemu DMA engine and also implement Accessed and Dirty bits page bits. If time allows IO MMU event counters starting with modifying ACPI tables to encode the right MMIO/IO MMU event counters capabilities, reserving MMIO region to the right alignment, reporting event counters configuration to IO MMU through MMIO and finally counting events.


Links:

Details:

  • Skill level: intermediate to advanced.
  • Language: C
  • Mentor: Jan Kiszka <jan.kiszka@web.de>
  • Mentor: Valentine Sinitsyn <valentine.sinitsyn@gmail.com>
  • Suggested by: David Kiarie

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.

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