Google Summer of Code 2015: Difference between revisions

From QEMU
(AMD IOMMU emulation)
Line 73: Line 73:
* Mentor: Hannes Reinecke <hare@suse.de>, John Snow <jsnow@redhat.com> (jsnow on QEMU IRC)
* Mentor: Hannes Reinecke <hare@suse.de>, John Snow <jsnow@redhat.com> (jsnow on QEMU IRC)
* Suggested by: Hannes Reinecke <hare@suse.de>
* Suggested by: Hannes Reinecke <hare@suse.de>
=== AMD IOMMU emulation ===
'''Summary:''' Rework existing AMD IOMMU emulation patches according to new IOMMU model of QEMU
There was already a proposal to add AMD IOMMU emulation in 2011, but QEMU was lacking a proper layer to integrate this effort smoothly. This is now possible like the successful integration of basic VT-d emulation demonstrated during last year's GSoC. So this task is a little bit simpler: study the old patches as well as the Intel version, port the old ones over the new interfaces, add ACPI tables (missing in the old version), ensure that the resulting IOMMU model works according to the AMD specification - and that guests like Linux/KVM can use it correctly. The model should also support interrupt remapping, but only for the user-space irqchip mode (kernel interface support is part of a different project proposal).
'''Links:'''
* [http://thread.gmane.org/gmane.comp.emulators.kvm.devel/73400 AMD IOMMU patches]
* [http://thread.gmane.org/gmane.comp.emulators.qemu/291304 VT-d emulation patches]
* [http://support.amd.com/FTechDocs/34434-IOMMU-Rev_1.26_2-11-09.pdf AMD IOMMU specification]
'''Details:'''
* Skill level: intermediate to advanced
* Language: C
* Mentor: Jan Kiszka <jan.kiszka@web.de>
* Suggested by: Jan Kiszka


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

Revision as of 16:01, 8 February 2015

Introduction

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

Students: GSoC 2015 organizations have not been announced yet and QEMU is not guaranteed a place. Please keep this in mind before investing too much effort in your application. There is enough time once orgs are announced to interact with us.

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.

QEMU projects

Integrate IDE ATAPI and SCSI CD-ROM emulation

Summary: Unify IDE ATAPI CD-ROM emulation with SCSI CD-ROM emulation to reduce code duplication and squash bugs

Currently the IDE ATAPI and SCSI CD-ROM emulated devices are two distinct implementations, and have different bugs/features. This leads to the situation that things which work when using the IDE emulation don't work when using the SCSI emulation and vice versa. So this project is for implementing a virtual ATA-to-SCSI bridge in QEMU, use this for emulating an IDE ATAPI drive, and merging the missing features from the IDE implementation into the SCSI one.

This project will allow you to expore IDE and SCSI storage protocols and learn how CD-ROM drives are operated.

Links:

Details:

  • Skill level: intermediate
  • Language: C
  • Mentor: Hannes Reinecke <hare@suse.de>, John Snow <jsnow@redhat.com> (jsnow on QEMU IRC)
  • Suggested by: Hannes Reinecke <hare@suse.de>

AMD IOMMU emulation

Summary: Rework existing AMD IOMMU emulation patches according to new IOMMU model of QEMU

There was already a proposal to add AMD IOMMU emulation in 2011, but QEMU was lacking a proper layer to integrate this effort smoothly. This is now possible like the successful integration of basic VT-d emulation demonstrated during last year's GSoC. So this task is a little bit simpler: study the old patches as well as the Intel version, port the old ones over the new interfaces, add ACPI tables (missing in the old version), ensure that the resulting IOMMU model works according to the AMD specification - and that guests like Linux/KVM can use it correctly. The model should also support interrupt remapping, but only for the user-space irqchip mode (kernel interface support is part of a different project proposal).

Links:

Details:

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

Libvirt projects

Introducing job control to the storage driver

Summary: 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

Enhancing libvirt-designer

Summary: The project is in its very early stage of life. 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

Summary: 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>

Abstracting device address allocation

Summary: There are many types of addresses that devices can have in libvirt's XML description. Not all address types are properly assigned and checked for duplicates. The goal of this is to have an abstract data structure that would handle assigning all kinds of addresses, handle duplicates, etc.

Links:

Details:

  • Skill level: beginner
  • Language: C
  • Mentor: Martin Kletzander <mkletzan@redhat.com>; mkletzan on IRC (OFTC and freenode)
  • Suggested by: Martin Kletzander


Admin interface APIs

Summary: We are currently working on an administrative interface for the libvirt daemon. This interface will be able to probe and change daemon settings live. Since this is going to be a new interface, there needs to be new APIs implemented. These APIs may do various interesting things strarting from showing the current logging filters up to force-disconnecting clients with certain properties. It is up to you what you would like to add, but of course this needs to be discussed and agreed on with the community.

Links:

Details:

  • Skill level: intermediate
  • Language: C
  • Mentor: Martin Kletzander <mkletzan@redhat.com>; mkletzan on IRC (OFTC and freenode)
  • Suggested by: Martin Kletzander

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.

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