Google Summer of Code 2014: Difference between revisions

From QEMU
No edit summary
 
(24 intermediate revisions by 7 users not shown)
Line 1: Line 1:
= Introduction =
= Introduction =


QEMU is applying as a mentoring organization for [http://google-melange.com/ Google Summer of Code 2014]. This page contains our ideas list and information for students and mentors.
QEMU is participating as a mentoring organization for [http://google-melange.com/ Google Summer of Code 2014]. This page contains our ideas list and information for students and mentors.
 
'''''Note to students'': Google has not yet announced participating organizations for 2014.  We do not know whether or not QEMU can participate this year, so use your time wisely and don't invest too much effort yet.'''


= Find Us =
= Find Us =


* IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
* IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
* IRC (development):
* IRC (development):
** QEMU: #qemu on irc.oftc.net
** QEMU: #qemu on irc.oftc.net
* Mailing list:
** libvirt: #virt on irc.oftc.net
** QEMU: http://lists.nongnu.org/mailman/listinfo/qemu-devel
** KVM: #kvm on chat.freenode.net
 
* Mailing lists:
** QEMU: [http://lists.nongnu.org/mailman/listinfo/qemu-devel qemu-devel]
** libvirt: [https://www.redhat.com/mailman/listinfo/libvir-list libvir-list]
** KVM: [http://www.linux-kvm.org/page/Lists,_IRC linux-kvm]


Please contact the mentor for the project idea you are interested in.  IRC is usually the quickest way to get an answer.
Please contact the mentor for the project idea you are interested in.  IRC is usually the quickest way to get an answer.
Line 19: Line 23:
* [[User:Stefanha|Stefan Hajnoczi]] (stefanha on IRC)
* [[User:Stefanha|Stefan Hajnoczi]] (stefanha on IRC)
* [[User:AnthonyLiguori|Anthony Liguori]] (aliguori on IRC)
* [[User:AnthonyLiguori|Anthony Liguori]] (aliguori on IRC)
= How to get familiar with our software =
See what people are developing and talking about on the mailing lists:
* [http://thread.gmane.org/gmane.comp.emulators.qemu/ qemu-devel]
* [https://www.redhat.com/archives/libvir-list/ libvir-list]
* [http://www.spinics.net/lists/kvm/ kvm]
Grab the source code or browse it:
* [http://git.qemu-project.org/?p=qemu.git;a=summary qemu.git]
* [http://libvirt.org/git/?p=libvirt.git;a=summary libvirt.git]
* [https://git.kernel.org/cgit/virt/kvm/kvm.git/ kvm.git]
Build QEMU and run it: [http://wiki.qemu-project.org/Hosts/Linux QEMU on Linux Hosts]


= Important links =
= Important links =
Line 24: Line 42:
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page FAQ]
* [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page FAQ]
* [http://www.google-melange.com/gsoc/events/google/gsoc2014 Program Timeline]
* [http://www.google-melange.com/gsoc/events/google/gsoc2014 Program Timeline]
* [http://blog.vmsplice.net/2011/03/advice-for-students-applying-to-google.html Advice for students applying (from 2011 but still relevant!)]


= Project Ideas =
= Project Ideas =


This is the listing of suggested project ideas. Students are free to suggest their own projects by emailing qemu-devel@nongnu.org and (optionally) CCing potential mentors.
This is the listing of suggested project ideas. Students are free to suggest their own projects by emailing qemu-devel@nongnu.org and (optionally) CCing potential mentors.
'''Note:''' These project ideas are also available to candidates applying for [[Outreach_Program_for_Women_Summer_2014|Outreach Program for Women]].


== QEMU projects ==
== QEMU projects ==
=== TianoCore support for Apple's boot.efi ===
'''Summary:''' Make TianoCore / OVMF support boot.efi for an out-of-the-box boot experience of Mac OS X
'''Accepted student:''' Reza Jelveh
The only way today to boot Mac OS X inside of QEMU / KVM is to go through a hacked up version of Apple's legacy BIOS boot loader. That solution is neither future proof nor streamlined for end users. Wouldn't it be nice if you could just do -cdrom 10.9.iso and the guest would boot straight into Mac OS X?
We're pretty close to get to that point. We do have a uEFI compatible firmware (OVMF) which is only missing HFS+ support and probably a few Apple proprietary interfaces that we have to mimick.
If we do finish early, there are a few items that we could try to tackle to make Mac OS X a first class citizen:
* e1000 EFI option rom to enable the link before XNU comes up
* MONITOR / MWAIT support in KVM
'''Links:'''
* [http://www.linux-kvm.org/page/OVMF OVMF KVM page]
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OvmfPkg OVMF TianoCore page]
* [https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/booting/booting.html XNU boot loader concepts]
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html#Apple Apple EFI boot loader concepts]
* [http://developer.apple.com./mac/library/DOCUMENTATION/Darwin/References/ManPages/man8/bless.8.html bless man page]
* [http://www.rodsbooks.com/refind/drivers.html HFS+ driver for EFI]
* [http://clover-wiki.zetam.org/What-is-what Clover description]
'''Details:'''
* Skill level: advanced
* Language: C
* Mentor: Alexander Graf <agraf@suse.de> (agraf on Freenode and OFTC)
* Suggested by: Alexander Graf
=== Intel IOMMU (VT-d) Emulation ===
'''Summary:''' Add support for emulating Intel IOMMUs according to the VT-d specification
'''Accepted student:''' Le Tan
The goal of this project is to provide a fully functional IOMMU to QEMU x86 guests. Primary use case would be the execution of hypervisors as QEMU guests. For this project, the IOMMU only needs to be usable for emulated PCI devices, not for assigned host devices (via VFIO e.g.). However, a VT-d emulation framework would also lay the ground for such support in the future, and more.
The Intel VT-d specification describes all the necessary registers and data structures. QEMU contains generic IOMMU support in its memory layer that shall be used in order to implement the necessary physical address translations during PCI DMA accesses. Furthermore, Knut Omang already created a VT-d framework that can be used as foundation for this project. Target QEMU machine would be the q35 chipset emulation. Nevertheless, the VT-d emulation layer shall be written in a way that it can easily be reused for future chipset emulations which will provide more VT-d features than q35 does (e.g. interrupt remapping). As time permits, some additional features could already be added so that q35 could be manually configured to expose them to guests although the real q35 chipset did not.
Minimally required VT-d features for q35 are:
* DMAR (DMA remapping) without PASID support
* Basic fault reporting
* IOTLBs (at least their invalidation feature, ideally also their caching properties)
* [anything else Linux requires to run]
There are at least two test cases available to validate the emulation:
* Linux guests that use VFIO and KVM
* The Jailhouse hypervisor
'''Links:'''
* [http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html VT-d specification]
* [https://github.com/knuto/qemu/commits/iommu_emu VT-d emulation framework by Knut Omang]
* [https://github.com/siemens/jailhouse Jailhouse hypervisor], specifically its [https://github.com/siemens/jailhouse/blob/master/hypervisor/arch/x86/vtd.c VT-d module]
'''Details:'''
* Skill level: advanced
* Language: C
* Mentor: Jan Kiszka <jan.kiszka@web.de>
* Suggested by: Jan Kiszka
=== Continuous vmstate testing ===
'''Summary:''' QEMU devices have a way to serialize their state.  The goal is to implement randomized save/reset/load device state tests.
'''Accepted student:''' sanidhya
QEMU can serialize state for its devices.  This feature is used by migration and save to disk.  We want to exercise that state to be sure that we are not missing state when we change device emulation code.  Given a tree of the devices, we can randomly choose a device, save its state to a buffer, reset the device (state that it has after boot), and load the state back every n milliseconds.  If it fails we know:
* which device is broken
* the state of the device
* what we were doing at the point of failure
By doing this project you will learn about live migration and device emulation.  When your testing tool discovers bugs you can delve into the affected device to fix it yourself or you can file bugs to get help from the maintainers.
'''Details:'''
* Skill level: intermediate
* Language: C
* Mentor: Juan Quintela <quintela@redhat.com> ("quintela" on IRC)
=== SPICE protocol fuzz testing ===
'''Summary''': Implement fuzz testing of client->server SPICE communications
'''Accepted student''': N/A
The SPICE protocol is used to access remotely a VM display, as well as to
redirect sound, USB, ... Any bug in the QEMU-side handling of the
SPICE protocol could be used to remotely compromise the host QEMU
runs on.
Fuzz testing is an automated random testing technique that explores a
program's code paths by trying random inputs. When the program under test
crashes, a bug has been found. These techniques have been used successfully
in other areas such as testing the Linux system call interface.
Your task is to implement fuzz tests for the client->server SPICE
communication. These tests will be merged into spice.git and part of the
test suite. You can either fix bugs found by your tests yourself, or work
with the community to report them and provide fixes.
You should consider different approaches to fuzzing that interest you.
Using an existing fuzzing framework may be a good idea too. SPICE has some
.proto files describing the data structures exchanged during SPICE
communication which can be used as a basis to build the fuzz tests.
'''Links''':
* https://en.wikipedia.org/wiki/Fuzz_testing
* [http://spice-space.org/ SPICE]
* [http://cgit.freedesktop.org/spice/spice-common/tree/spice.proto SPICE protocol description]
* [http://codemonkey.org.uk/projects/trinity/ Trinity Linux system call fuzzer]
'''Details''':
* Skill level: intermediate
* Language: Python and/or shell
* Mentor: Christophe Fergeau <cfergeau@redhat.com> (teuf on IRC)


=== Device driver framework for low-level testing ===
=== Device driver framework for low-level testing ===
   
   
'''Summary:''' Implement bus drivers and example device tests  
'''Summary:''' Implement bus drivers and example device tests  
'''Accepted student''': Marc Marí
   
   
It is currently very hard to exercise device emulation code and, as a result,
Modern hardware requires elaborate setup before it can be accessed. So much low-level configuration is necessary before devices become available that we (mostly) don't bother to write test cases for emulated devices.  This project is going to change that - let's make testing emulated devices easy!
most device emulation code does not have tests.  The reason for this is that
modern hardware is complex and often requires elaborate setup before it can be
accessed. When applicable, we also want to test the same devices under multiple
emulated boardThe same test should apply to all boards, just like Linux uses
the same network card driver on any system where you can plug that card in.


The analogy with Linux is not a coincidence; a good device testing framework is
QEMU's libqos library aims to provide a device driver framework for writing PCI, I2C, fw_cfg, and other device tests. libqos has several areas that need improvement before emulated device testing becomes generally useful:
really very similar to the plug-and-play subsystem of a "real" operating
system. So far we didn't have any of this, and it made testing QEMU device emulation
code was "too hard"... but this project will change that!


QEMU has a mode called 'qtest' where it simulates the machine without running
* Add support for virtioThis requires you to implement at least one of the virtio transports: virtio-pci, virtio-mmio, or virtio-ccw.
guest codeInstead, qtest exposes a protocol for accessing memory, detecting
interrupts, and stepping the clock.  Tests use qtest mode to verify that an
emulated device operates according to its specification.


For example, a test case can program the timer chip and then step the clock,
* Add support for USB.  This requires you to implement at least one USB Host Controller driver: xHCI, EHCI, UHCI, or OHCI.
checking if the timer interrupt has been raised.
 
* Add I2C/SMBus controller drivers for pc (i440fx) and pc-q35 (ICH9) x86 machines.
 
* Add PCI controller drivers for ppc machines.
 
* Make device test cases work for multiple machine types. For example, a PCI network card test case should work on both x86 and ppc machines. This requires that you first implement more controller drivers (see above). Some busses, like PCI, can detect devices and therefore decide which device tests to execute for the emulated machine.
 
Pick one or more of these areas to work on.
 
This project will give you an opportunity to work on low-level device driver code, learn how modern hardware works, and familiarize yourself with device driver frameworks. The libqos approach is similar to kernel device driver frameworks that Linux, FreeBSD, Windows, or Darwin have. If you are not familiar with device drivers already, make sure to look at the free Linux Device Drivers book to get some background.


In order to do this for more complex PCI, I2C, ISA, and USB devices, we need
the equivalent of device driver frameworks that operating system kernels have.
Right now, QEMU's libqos provides a meager set of device driver APIs but much
more is necessary before test cases can be expressed concisely without a
lot of setup.
'''Links:'''
'''Links:'''
* [http://git.qemu-project.org/?p=qemu.git;a=tree;f=tests/libqos;h=7b67620d176feb10e40c4278957d1f6a65dea4df;hb=HEAD libqos]
* [http://git.qemu-project.org/?p=qemu.git;a=tree;f=tests/libqos;h=7b67620d176feb10e40c4278957d1f6a65dea4df;hb=HEAD libqos]
* [http://git.qemu-project.org/?p=qemu.git;a=blob;f=tests/ide-test.c;h=4a0d97f19764b6f704f94e6fe8e17dc32e7104bc;hb=HEAD IDE controller test case]
* [http://git.qemu-project.org/?p=qemu.git;a=blob;f=tests/ide-test.c;h=4a0d97f19764b6f704f94e6fe8e17dc32e7104bc;hb=HEAD IDE controller test case]
* Linux kernel device driver model [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/device.h header file] and [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-model documentation]
* Linux kernel device driver model [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/device.h header file] and [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-model documentation]
* [https://lwn.net/Kernel/LDD3/ Linux Device Drivers, 3rd Edition]
   
   
'''Details:'''
'''Details:'''
Line 74: Line 207:
   
   
'''Summary:''' Implement fuzz testing for image file formats to identify security vulnerabilities before the bad guys do
'''Summary:''' Implement fuzz testing for image file formats to identify security vulnerabilities before the bad guys do
'''Accepted student''': Maria Kustova (via Outreach Program for Women)
   
   
QEMU supports a range of image file formats including qcow2, VMDK, and VHDX.
QEMU supports a range of image file formats including qcow2, VMDK, and VHDX.
Line 105: Line 240:
* Language: Python and/or shell
* Language: Python and/or shell
* Mentor: Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)
* Mentor: Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)
=== Incremental backup of block images ===
'''Summary:''' Implement persistent incremental image backup.
'''Accepted student''': N/A
Users want to do regular backup of VM image to protect data from
unexpected loss.  Incremental backup is a backup strategy that only copies out
the "new data" that is changed since previous backup, to reduce the overhead of
backup and improve the storage utilization. To track which part of guest data
is changed, QEMU needs to store image's "dirty bitmap" on the disk as well as
the image data itself.
The task is to implement a new block driver (a filter) to load/store this
persistent dirty bitmap file, and maintain the dirty bits while the guest
writes to the data image. As a prerequisite, you also need to make the design
of this bitmap file format. Then, design test cases and write scripts to test
the driver.
The persistent bitmap file must contain:
* Magic bits to identify the format of this file.
* Bitmap granularity (e.g. 64 KB)
* The actual bitmap (1 TB disk @ 64 KB granularity = 2 MB bitmap)
* Flags including a "clean" flag. The "clean" flag is used to tell whether the persistent bitmap file is safe to use again.  When QEMU opens the persistent dirty bitmap, it clears the "clean" flag.  When QEMU deactivates and finishes writing out the dirty bitmap, it sets the "clean" flag.  If the QEMU process crashes it is not safe to trust the dirty bitmap; a full backup must be performed. Make use of this flag in the driver to limit the performance overhead.
'''Links:'''
* http://en.wikipedia.org/wiki/Incremental_backup
* [http://lists.nongnu.org/archive/html/qemu-devel/2014-01/msg02156.html QMP: Introduce incremental drive-backup with in-memory dirty bitmap]
'''Details:'''
* Skill level: intermediate
* Language: C
* Mentors: Fam Zheng <famz@redhat.com> (fam on IRC), Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)


== Libvirt projects ==
== Libvirt projects ==


=== Introducing job control to the storage driver ===
=== Introducing job control to the storage driver ===
'''Accepted student''': TuckerD


Currently, libvirt support job cancellation and progress reporting on domains.
Currently, libvirt support job cancellation and progress reporting on domains.
Line 119: Line 291:


* Skill level: intermediate
* Skill level: intermediate
=== Rewriting VirtualBox driver ===
'''Accepted students''': Taowei Luo
If you have ever looked into our VirtualBox driver, you still may experience occasional headaches. I still do. The code is horribly structured so we would be more than happy to have somebody to rewrite the code and bring cleanliness that we strive to keep in the rest of the code.
* Skill level: beginner
=== Enhancing libvirt-snmp or libvirt-designer ===
'''Accepted student''': T A Mahadevan for libvirt-snmp
Both project are in their very early stage of life. [http://wiki.libvirt.org/page/Libvirt-snmp Libvirt-snmp] aims to provide libvirt APIs over SNMP, so various network monitoring systems can access statistics of virtual machines. The [https://www.redhat.com/archives/libvirt-announce/2012-October/msg00003.html libvirt-designer] tries to ease generation of libvirt XML with coworking with libosinfo project. Contact me and we can find something suitable.
* Skill level: beginer
=== Making virsh more bash like ===
'''Accepted student''': N/A
If you have ever used virsh, you certainly reached the point where you stuggle with its user friendliness. Or unfriendliness I should rather say. Virsh is missing a lot of bash functionality that users consider natural: from automatic completion of object names, through redirecting command outputs through piping commands together. The aim would be to make these functions available in virsh and thus make user experience better.
* Skill level: Advanced


=== Your own idea ===
=== Your own idea ===
Line 165: Line 361:


The mentor chooses their student by reviewing student application forms and conducting IRC interviews with candidates.  Depending on the number of candidates, this can be time-consuming in itself.  Choosing the right student is critical so that both the mentor and the student can have a successful experience.
The mentor chooses their student by reviewing student application forms and conducting IRC interviews with candidates.  Depending on the number of candidates, this can be time-consuming in itself.  Choosing the right student is critical so that both the mentor and the student can have a successful experience.
[[Category:GSoC]]

Latest revision as of 15:08, 16 February 2016

Introduction

QEMU is participating as a mentoring organization for Google Summer of Code 2014. This page contains our ideas list and information for students and mentors.

Find Us

  • IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
  • IRC (development):
    • QEMU: #qemu on irc.oftc.net
    • libvirt: #virt 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 GSoC, 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

Important links

Project Ideas

This is the listing of suggested project ideas. Students are free to suggest their own projects by emailing qemu-devel@nongnu.org and (optionally) CCing potential mentors.

Note: These project ideas are also available to candidates applying for Outreach Program for Women.

QEMU projects

TianoCore support for Apple's boot.efi

Summary: Make TianoCore / OVMF support boot.efi for an out-of-the-box boot experience of Mac OS X

Accepted student: Reza Jelveh

The only way today to boot Mac OS X inside of QEMU / KVM is to go through a hacked up version of Apple's legacy BIOS boot loader. That solution is neither future proof nor streamlined for end users. Wouldn't it be nice if you could just do -cdrom 10.9.iso and the guest would boot straight into Mac OS X?

We're pretty close to get to that point. We do have a uEFI compatible firmware (OVMF) which is only missing HFS+ support and probably a few Apple proprietary interfaces that we have to mimick.

If we do finish early, there are a few items that we could try to tackle to make Mac OS X a first class citizen:

  • e1000 EFI option rom to enable the link before XNU comes up
  • MONITOR / MWAIT support in KVM

Links:

Details:

  • Skill level: advanced
  • Language: C
  • Mentor: Alexander Graf <agraf@suse.de> (agraf on Freenode and OFTC)
  • Suggested by: Alexander Graf

Intel IOMMU (VT-d) Emulation

Summary: Add support for emulating Intel IOMMUs according to the VT-d specification

Accepted student: Le Tan

The goal of this project is to provide a fully functional IOMMU to QEMU x86 guests. Primary use case would be the execution of hypervisors as QEMU guests. For this project, the IOMMU only needs to be usable for emulated PCI devices, not for assigned host devices (via VFIO e.g.). However, a VT-d emulation framework would also lay the ground for such support in the future, and more.

The Intel VT-d specification describes all the necessary registers and data structures. QEMU contains generic IOMMU support in its memory layer that shall be used in order to implement the necessary physical address translations during PCI DMA accesses. Furthermore, Knut Omang already created a VT-d framework that can be used as foundation for this project. Target QEMU machine would be the q35 chipset emulation. Nevertheless, the VT-d emulation layer shall be written in a way that it can easily be reused for future chipset emulations which will provide more VT-d features than q35 does (e.g. interrupt remapping). As time permits, some additional features could already be added so that q35 could be manually configured to expose them to guests although the real q35 chipset did not.

Minimally required VT-d features for q35 are:

  • DMAR (DMA remapping) without PASID support
  • Basic fault reporting
  • IOTLBs (at least their invalidation feature, ideally also their caching properties)
  • [anything else Linux requires to run]

There are at least two test cases available to validate the emulation:

  • Linux guests that use VFIO and KVM
  • The Jailhouse hypervisor

Links:

Details:

  • Skill level: advanced
  • Language: C
  • Mentor: Jan Kiszka <jan.kiszka@web.de>
  • Suggested by: Jan Kiszka

Continuous vmstate testing

Summary: QEMU devices have a way to serialize their state. The goal is to implement randomized save/reset/load device state tests.

Accepted student: sanidhya

QEMU can serialize state for its devices. This feature is used by migration and save to disk. We want to exercise that state to be sure that we are not missing state when we change device emulation code. Given a tree of the devices, we can randomly choose a device, save its state to a buffer, reset the device (state that it has after boot), and load the state back every n milliseconds. If it fails we know:

  • which device is broken
  • the state of the device
  • what we were doing at the point of failure

By doing this project you will learn about live migration and device emulation. When your testing tool discovers bugs you can delve into the affected device to fix it yourself or you can file bugs to get help from the maintainers.

Details:

  • Skill level: intermediate
  • Language: C
  • Mentor: Juan Quintela <quintela@redhat.com> ("quintela" on IRC)

SPICE protocol fuzz testing

Summary: Implement fuzz testing of client->server SPICE communications

Accepted student: N/A

The SPICE protocol is used to access remotely a VM display, as well as to redirect sound, USB, ... Any bug in the QEMU-side handling of the SPICE protocol could be used to remotely compromise the host QEMU runs on.

Fuzz testing is an automated random testing technique that explores a program's code paths by trying random inputs. When the program under test crashes, a bug has been found. These techniques have been used successfully in other areas such as testing the Linux system call interface.

Your task is to implement fuzz tests for the client->server SPICE communication. These tests will be merged into spice.git and part of the test suite. You can either fix bugs found by your tests yourself, or work with the community to report them and provide fixes.

You should consider different approaches to fuzzing that interest you. Using an existing fuzzing framework may be a good idea too. SPICE has some .proto files describing the data structures exchanged during SPICE communication which can be used as a basis to build the fuzz tests.

Links:

Details:

  • Skill level: intermediate
  • Language: Python and/or shell
  • Mentor: Christophe Fergeau <cfergeau@redhat.com> (teuf on IRC)

Device driver framework for low-level testing

Summary: Implement bus drivers and example device tests

Accepted student: Marc Marí

Modern hardware requires elaborate setup before it can be accessed. So much low-level configuration is necessary before devices become available that we (mostly) don't bother to write test cases for emulated devices. This project is going to change that - let's make testing emulated devices easy!

QEMU's libqos library aims to provide a device driver framework for writing PCI, I2C, fw_cfg, and other device tests. libqos has several areas that need improvement before emulated device testing becomes generally useful:

  • Add support for virtio. This requires you to implement at least one of the virtio transports: virtio-pci, virtio-mmio, or virtio-ccw.
  • Add support for USB. This requires you to implement at least one USB Host Controller driver: xHCI, EHCI, UHCI, or OHCI.
  • Add I2C/SMBus controller drivers for pc (i440fx) and pc-q35 (ICH9) x86 machines.
  • Add PCI controller drivers for ppc machines.
  • Make device test cases work for multiple machine types. For example, a PCI network card test case should work on both x86 and ppc machines. This requires that you first implement more controller drivers (see above). Some busses, like PCI, can detect devices and therefore decide which device tests to execute for the emulated machine.

Pick one or more of these areas to work on.

This project will give you an opportunity to work on low-level device driver code, learn how modern hardware works, and familiarize yourself with device driver frameworks. The libqos approach is similar to kernel device driver frameworks that Linux, FreeBSD, Windows, or Darwin have. If you are not familiar with device drivers already, make sure to look at the free Linux Device Drivers book to get some background.

Links:

Details:

  • Skill level: intermediate to advanced
  • Language: C
  • Mentor: Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC), Paolo Bonzini <pbonzini@redhat.com>

Disk image fuzz testing

Summary: Implement fuzz testing for image file formats to identify security vulnerabilities before the bad guys do

Accepted student: Maria Kustova (via Outreach Program for Women)

QEMU supports a range of image file formats including qcow2, VMDK, and VHDX. Image files are often uploaded by untrusted users to cloud providers or shared online as untrusted "demo appliances". Any bug in QEMU that can be triggered by a malicious image file could be used to compromise the host opening the image file.

Fuzz testing is an automated random testing technique that explores a program's code paths by trying random inputs. When the program under test crashes, a bug has been found. These techniques have been used successfully in other areas such as testing the Linux system call interface.

Your task is to implement fuzz tests for qcow2, VMDK, and VHDX. These tests will be merged into qemu.git and part of the test suite. You can either fix bugs found by your tests yourself, or work with the community to report them and provide fixes.

You should consider different approaches to fuzzing that interest you (e.g. combining with code coverage metrics). Using an existing fuzzing framework may be a good idea too.

Links:

Details:

  • Skill level: intermediate
  • Language: Python and/or shell
  • Mentor: Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)

Incremental backup of block images

Summary: Implement persistent incremental image backup.

Accepted student: N/A

Users want to do regular backup of VM image to protect data from unexpected loss. Incremental backup is a backup strategy that only copies out the "new data" that is changed since previous backup, to reduce the overhead of backup and improve the storage utilization. To track which part of guest data is changed, QEMU needs to store image's "dirty bitmap" on the disk as well as the image data itself.

The task is to implement a new block driver (a filter) to load/store this persistent dirty bitmap file, and maintain the dirty bits while the guest writes to the data image. As a prerequisite, you also need to make the design of this bitmap file format. Then, design test cases and write scripts to test the driver.

The persistent bitmap file must contain:

  • Magic bits to identify the format of this file.
  • Bitmap granularity (e.g. 64 KB)
  • The actual bitmap (1 TB disk @ 64 KB granularity = 2 MB bitmap)
  • Flags including a "clean" flag. The "clean" flag is used to tell whether the persistent bitmap file is safe to use again. When QEMU opens the persistent dirty bitmap, it clears the "clean" flag. When QEMU deactivates and finishes writing out the dirty bitmap, it sets the "clean" flag. If the QEMU process crashes it is not safe to trust the dirty bitmap; a full backup must be performed. Make use of this flag in the driver to limit the performance overhead.

Links:

Details:

  • Skill level: intermediate
  • Language: C
  • Mentors: Fam Zheng <famz@redhat.com> (fam on IRC), Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)

Libvirt projects

Introducing job control to the storage driver

Accepted student: TuckerD

Currently, libvirt support job cancellation and progress reporting on domains. That is, if there's a long running job on a domain, e.g. migration, libvirt reports how much data has already been transferred to the destination and how much still needs to be transferred. However, libvirt lacks such information reporting in storage area, to which libvirt developers refer to as the storage driver. The aim is to report progress on several storage tasks, like volume wiping, file allocation an others.

  • Skill level: intermediate

Rewriting VirtualBox driver

Accepted students: Taowei Luo

If you have ever looked into our VirtualBox driver, you still may experience occasional headaches. I still do. The code is horribly structured so we would be more than happy to have somebody to rewrite the code and bring cleanliness that we strive to keep in the rest of the code.

  • Skill level: beginner

Enhancing libvirt-snmp or libvirt-designer

Accepted student: T A Mahadevan for libvirt-snmp

Both project are in their very early stage of life. Libvirt-snmp aims to provide libvirt APIs over SNMP, so various network monitoring systems can access statistics of virtual machines. The libvirt-designer tries to ease generation of libvirt XML with coworking with libosinfo project. Contact me and we can find something suitable.

  • Skill level: beginer

Making virsh more bash like

Accepted student: N/A

If you have ever used virsh, you certainly reached the point where you stuggle with its user friendliness. Or unfriendliness I should rather say. Virsh is missing a lot of bash functionality that users consider natural: from automatic completion of object names, through redirecting command outputs through piping commands together. The aim would be to make these functions available in virsh and thus make user experience better.

  • Skill level: Advanced

Your own idea

Just catch me (Michal Privoznik) on IRC and we can discuss what interests you.

Links:

Details:

  • Component: libvirt
  • Skill level: (see description to each item)
  • Language: C
  • Mentor: Michal Privoznik <mprivozn@redhat.com>, mprivozn on IRC (#virt OFTC)
  • Suggested by: Michal Privoznik <mprivozn@redhat.com>

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 student and assessing the student's progress. GSoC has a mid-term evaluation and a final evaluation where both the mentor and student assess each other.

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

The mentor chooses their student by reviewing student application forms and conducting IRC interviews with candidates. Depending on the number of candidates, this can be time-consuming in itself. Choosing the right student is critical so that both the mentor and the student can have a successful experience.