Archived/GSoc 2011 Ideas

Project Ideas for GSoC 2011

This page is used to list project ideas for Google Summer of Code (GSOC) 2011.

Key pages

• Xen.org GSoc Page
• GSoC 2011 timeline : next major deadline April 25 19:00 UTC, Accepted student proposals announced on the Google Summer of Code 2011 site

Applying for a project

• It is good practive to discuss a proposal with the mentor beforehand.
  • You can do this via e-mail (make sure you include GSoC and the project title in the subject
  • By arranging an IRC meeting at a specific time using #xen-gsoc IRC channel on freenode with your mentor
  • We will choose students based on a combination of criteria covering: quality of submission, the student's ideas on how to deliver the project, how much of the idea actually came from the student (we don't want the mentor to have written the application), social skills, enthusiasm, whether we believe the student will fit well into the community and whether we believe the student will deliver the project
• You can find our GSoC_Student_Application_Template (there are two examples at the bottom of the page) and the Xen.org GSoc Page
• To apply you need to create a profile on the google system. To do this, go to Xen.org@GSoc
• There is a big Students: apply! with an orange Register Button underneath
  • As part of the registration process you will be asked to create a Google account. If you have one, you can use it to log in. Otherwise you will need to create one.
  • Once you are logged in, you will be led to a Register as Student page; see here for the page and here for instructions
• You should now see a Submit your Student Proposal link in the left hand navigation menu. For more instructions see here.
• There is also a GSoC 2011 user guide. If you are struggling, please use the #gsoc IRC channel on freenode to get further help.

Resources

• There is a #xen-gsoc IRC channel on freenode which you can use to arrange an IRC meeting with your prospective mentors
• We were also planning an IRC meeting on this channel on March 31st 13:00 - 17:00 BST (GMT+1)
• The DO's & DONT's for GSoC student edition

Mentor information

• Google system Guide for Mentors. In a nutshell you need to register with Google, create a profile and register as mentor by going to Xen.org@GSoc and start by clicking on Or register as a mentor (the link is just underneath the link to ourt ideas page).
• Mentor's handbook - The following sections are worth having a look at (each chapter is the size of an A4 page)
  • Getting Started : What Makes a Good Mentor
  • Getting Started : Selecting A Student
  • Communication : The entire section is a good read, however Best Practices and Warning Signs are a must
  • Mentoring: The entire section is a good read, however Setting Expectations, Managing The Plan and Evaluations are a must

Project Ideas

Rules

• Be creative
• Be specific: what do you want to be implemented; if at all possible provide an indication of size and complexity as described above to make it easier for a student to choose ideas
• If you are willing to mentors those ideas, add your name and email to the idea.
• If you're an interested student, add your name and email next to the idea. It is ok to have several students interested by one idea.
• Aspiring students need to get in touch with the xen.org community manager via community.manager@xen.org to register their interest

New Project Ideas

Please add new ideas with a description or mail community.manager@xen.org if in doubt. - This is now closed for 2011 GSoC: please do NOT edit this section. It will not have any effect!

Description	Project	Possible Mentor(s)	Size, Knowledge required	Detailed Description
Virtio on Xen	Xen	stefano.stabellini AT eu.citrix.com	Qemu, Xen, Linux	Virtio is a set of paravirtualized hardware, with the backends living in qemu and the frontends in the linux kernel and other operating systems. The virtio devices are typically used on the KVM hypervisor but they are not hypervisor specific, so they should be able to run on Xen without too many changes. This project involves working on upstream qemu to make sure that the virtio devices can run on Xen and then do they same with the linux kernel. Producing a benchmark to compare the performances of virtio against netback/netfront and blkback/blkfront would be ideal.
PV audio	Xen	stefano.stabellini AT eu.citrix.com AND/OR konrad.wilk AT oracle.com	Audio, QEMU, Protcols, PulseAudio or ALSA	Xen PV guests rely on paravirtualized hardware to access disk, network and console. The frontend is a driver living in the guest's kernel and the backend usually lives in the dom0 Linux kernel or within Qemu in userspace. This project involves designing and implementing a new PV audio protocol following the common pattern used by the PV network, disk and console protocols. The frontend/backend drivers pair should be implemented for Linux hooking into PulseAudio (or ALSA).
Add Xen PV block device support to SeaBIOS	Xen	Ian.Campbell AT citrix.com	C coding, Xen, Qemu	This project's goal is to add support the SeaBIOS to allow guest OSes to be booted directly from PV disk devices rather than from the emulated disk device. The aim will be to add sufficient support to SeaBIOS to allow it to negotiate device setup via XenBus, satisfy disk I/O requests made via the BIOS int 0x13 interface and finally teardown such that the guest OSes PV drivers can subsequently initialise correctly without needing to be aware that int 0x13 had done this. Extensions to this work could include adding PV network support in order to enable PXE boot.
EFI in HVM guests + Xen on EFI Hardware	Xen	Tim.Deegan AT eu.citrix.com or stefano.stabellini AT eu.citrix.com	Low-level C and x86 assembler, some familiarity with BIOSes and EFI	Core tasks: replace the ROM BIOS and related firmware that is presented to a Xen HVM guest with an EFI firmware (e.g. one based on TianoCore). Supplementary tasks: make appropriate changes to Xen and/or GrUB2 to enable Xen to boot on hardware that provides only an EFI firmware. Rationale: EFI is becoming more widespread; in the next few years we can expect to see OSes that require it, and eventually hardware may stop providing the old BIOS interfaces. Xen should keep up with this, both in the virtual machine it provides and in the hardware it runs on.
gcov	Xen	george.dunlap AT eu.citrix.com, possibly with support from lars.kurth AT xen.org	Systems programming in C. Familiarity with build systems, compilers, linkers, and executable formats would be helpful.	gcov is a test coverage program that's part of the gcc suite of utilities. gcov will instrument a program and tell you, for a given execution how many times each line of code is executed. This is useful for both testing and profiling: testing, to find out what part of your program is being touched by your tests, and profiling to find out which parts of your code are being executed most frequently (and would thus benefit from optimization). gcov has already been ported to the Linux kernel in the form of lcov, and includes many tools for analyzing the entire source tree. Some patches have been submitted which port gcov to Xen as well, and allow it to make use of lcov's reporting facility. However, they were never made acceptable for inclusion in mainline xen. This project would include re-porting those patches to Xen 4.1, making them work, and making whatever changes are necessary to include them upstream. After that, the project would involve working with the maintainer of xen.org's automated test system to analyze which parts of Xen are being tested well and poorly, and potentially designing tests which will exercise important code which is not tested very well.
Add tests for more features to the Open Source Xen automatic tests	Xen	ian.jackson AT eu.citrix.com	Perl, since the support libraries used for writing tests are Perl. Ability to write reliable Unix programs which use ssh to run commands on other hosts, etc.	Core tasks: Identify important features and modes of use of Xen which are not currently tested by the automatic tests. Add appropriate tests. Rationale: The automatic regression test system tests only a subset of Xen's functionality. We would like to improve this to reduce the risk of regressions and improve the code quality.
Kemari/Remus: high availability on xen and libxl	Xen	Tim.Deegan AT eu.citrix.com	Systems programming in C/POSIX, including network comms. Some kernel programming experience would be useful.	Core tasks: build a high-availability/failover system based on either Remus (a rolling-checkpoint system that it currently part of the Xen tree) or Kemari (a similar project that currently runs on KVM), and integrate it with the libxc and libxl toolstack components.
Fancier web reporting for xen.org automated tests	Xen	Ian.Jackson AT eu.citrix.com, with support from lars.kurth AT xen.org	website programming, SQL	Core tasks: build a dynamic website which allows browsing and querying of tests performed by the automatic Open Source Xen tests. Rationale: The automatic tests currently produce statically-generated HTML output. This gives and inflexible view and makes querying for particular tests difficult. We would like a dynamically-generated set of pages. These should be accessible and useable in any browser without the use of Javascript; Javascript and AJAX may be used as optional extras to enhance the user interface. Usage of open source, web based test results visualization packages such as WebVizOr or similar is fine and encouraged.
Machine Check Exceptions (MCE)	Xen	mukesh.rathor AT oracle.com		Xen injects Machine Check Exceptions into guests. I have done basic testing of MCE injections into guests for memory faults using a software test driver. Given a page frame and guest id, it will inject LLC error by programming the MSRs and doing int18 in xen. My testing was xen4.0.2. I found guests are properly shutdown and dom0 is properly logging errors. Missing pieces are: 1) PV GUEST: newer kernels, pv-ops kernel, etc. has MCE handler. Xen will call this handler if the guest has registered it in the IDT with xen. PV-OPS is not doing this because the handler runs on its IST (interrupt stack table). So, it needs to be explored if for xen we can just ignore the IST and let MCE handler run on normal kernel stack. 2) HVM guest: The error is injected into the VMX container for guest to pick it up. Newer kernels with MCE handler should pick it up and offline pages if possible. This needs to be tested. 3) Dom0: currently, mcelog just maps the page to DIMM using SMBIOS info which is not very reliable at all. A diagnostic engine needs to be devised which can do this mapping and point to exact DIMM to replace upon memory errors, or CPU in case of cpu errors, etc.
Mirage SSL	XCP	(Anil Madhavapeddy) anil AT recoil.org	OCaml programming, Functional programming, Familiarity with cryptography	Mirage is an OCaml programming framework that can compile code directly into Xen microkernels, or normal UNIX binaries. It is event driven and heavily relies on the Lwt threading library. This project will have you implement a clean-slate implementation of the SSL protocol in OCaml (no use of OpenSSL). Ideally, you will break down the protocol into clean components, and provide a layered Lwt-compliant implementation of SSL that handles negotiating a connection and maintaining it (rekeying, etc). Emphasis on functionality and minimising data copying, and benchmarking it versus OpenSSL to characterise the performance difference. If the library is pure-OCaml, you will not need to have a Xen installation, as Mirage will compile to UNIX also. But kernel programmers have more fun :)
Generic balloon API in Linux	Upstream	konrad.wilk AT oracle.com	Linux kernel, hypervisors	Unify the Xen memory allocation/deallocation (balloon) driver with other balloon drivers to provide a generic front which Linux kernel can utilize. This provides the benfit of having one point for the Linux hotplug memory to call in the balloon drivers. This work involves looking at other hypervisors solutions (KVM, Xen, HyperV, VMWare). If there is enough time, also try to utilize the shrinker API which the filesystem API provides to decrease memory consumption when under high memory pressure. The primary goal is upstream (Linux) these patches for 2.6.40 acceptance.
XCP and OpenNebula Integration	XCP	tinova AT opennebula.org	Medium sized, knowledge of XCP, OpenNebula, Ruby and IaaS	OpenNebula is an open source virtual infrastructure which supports various hypervisors, including Xen. This project aims to integrate OpenNebula and XCP, including a research on which interface to use, XAPI or the "xe" command. This integration will include virtual networking integration between OpenNebula and XCP and XCP virtual machine lifecycle management through OpenNebula
Port a traditional Unix libc to the Xen PV platform	Xen	ian.jackson AT eu.citrix.com	Understanding of the Unix programming environment; embedded programming and cross-compiling; low-level C and perhaps some assembler	Core tasks: Port the NetBSD or FreeBSD libc to run directly on Xen, treating the Xen paravirtualised platform as an embedded environment. Provide emulations of relevant system calls, and stubbed ENOSYS functions for irrelevant ones. Port one or more existing programs to this platform. Reuse or replace existing code as appropriate. Supplementary tasks: Port the qemu device model used by Xen for hardware emulation of fully-virtualised (HVM) guests to the new environment. Port the Ocaml "xenstored" to the new environment. Provide a standalone diagnostic guest which can examine the PV environment, issue Xen calls, run tests, etc. Rationale: Currently we have some very small guests in Xen systems for device emulation (a port of qemu) and management functions (xenstored); these use the "newlib" C library on top of an ad-hoc Xen layer. This is fragile, difficult to port to, and contains a number of awkward layering violations. We need a more posix-like environment, which used a fully-featured Unix libc and is easier to port other software to.
Linux based stubdoms	Xen	stefano.stabellini AT eu.citrix.com	Qemu, Linux	Stubdoms are very small Xen PV guests used to run some software components that otherwise live in dom0. This way we reduce the memory and cpu usage of Dom0, improving the overall stability of the system. Currently we use MiniOS as kernel for these PV guests but we would like to see Linux based stubdoms as well. Typical stubdoms are: 1) Qemu based stubdoms, each of them providing devices emulation to a particular HVM guest, running Qemu on MiniOS; 2) oxenstored based stubdom, only one in the system that runs oxenstored on MiniOS. The challenge of this project is to configure a Linux based PV guest running Qemu and/or oxenstored so that the overall memory usage is comparable to the one of a MiniOS based stubdom. Producing a benchmark to measure the resource usage and the level of performances of a Linux stubdom in comparison with a MiniOS stubdom is required. Modifications to the Linux kernel and Qemu are probably needed to reach the goal.
Migrating xen api to libxenlight	Xen	Steven Maresca	N/A	Proposal by student
Recovery of crashed Linux	Xen	konrad.wilk AT oracle.com	Knowledge of IO-APIC/LAPIC, C is needed.	kexec/kdump is a mechanism for the Linux kernel to start a small tiny copy of itself if the main kernel goes BOOM and dump the contents of the memory to a remote location (disk, USB stick, scp, NFS, etc). Since a Linux KA-BOOM (or a Xen hypervisor) is catastrophic, the hardware is in unknown state so the kexec/kdump kernel has to be delicate in initializing the devices. This project would require looking at past attempts, seeing what is required to make this work with Xen hypervisor and Linux pvops kernel.
Investigation: XenDbg - Xen Debugger support	XCP	jonathan.ludlam AT eu.citrix.com with suppport from lars.kurth AT xen.org	Medium to large sized, Debug, Linux, Kernel	This project's goal is to investigate how debug support can be added to Xen, with some prototyping. The topic is fairly flexible and we can break it down. The main goal is that others in the community can build on the work done as part of this project. Components / tasks that could be covered by the investigation: 1) Investigate how much of Linux KGDB (in the kernel since 2.6.26) or GDB can be used out-of-the-box and whether\what hooks would be needed in the hypervisor or Dom0 such that it can be debugged. Document issues and how much works\does not work. 2) Investigate the debugger landscape and see whether there are any graphical front-ends for KGDB (e.g. in Eclipse) that could be used and document. 3) Investigate whether Xen core components like memory management info can be exposed through core Xen debugging commands from within a debugger. 4) Areas of Xen debugging have shown problems in the past are: "symbol handling" leading to broken call-stacks, crash dump generation, and others.
Parallax SM backend	XCP	Julian.chesterfield AT citrix.com	Medium sized	The parallax website describes parallax as a more flexible storage system is needed to support rapid virtual machine creation and state capture. Parallax can perform very low overhead snapshots, and can quickly provision new volumes based on template images. Similar to the DRBD and OCFS2 suggestions above, a new storage plugin could be created which interfaces XCP to a parallax service.
Extend ocamldebug to support multiple threads	XCP	jonathan.knowlesAT eu.citrix.com, jonathan.ludlam AT eu.citrix.com with support from lars.kurth AT xen.org	Medium to large, OCaml, Debug	The OCaml distribution comes with a debugger called OCamlDebug. While OCamlDebug comes with support for remote debugging (over a network connection), it has no support for multiple threads. Since Xapi makes significant use of threading, it's not currently possible to use OcamlDebug to debug remote Xapi instances. As a workaround for the lack of a proper debugger, developers often resort to inserting logging statements in their code. However, this method requires developers to recompile their code and restart the Xapi instance of interest - in the process often losing the state they had hoped to inspect. A successful project should achieve the following: 1) extend the over-the-wire protocol between OCamlDebug and OCamlRun to support multiple threads 2) extend OCamlRun and OCamlDebug to support this protocol (as a prototype) 3) Depending on how far the project gets, generate a set of patches to the OCaml distribution. To get started /technologies/core/toolsapis/jpda/ Examine how multi-threaded debugging works in other languages and read up on and/or reverse-engineer the existing OCamlDebug protocol.
Guest RPC mechanism	XCP	jonathan.ludlam AT eu.citrix.com	Medium to Large, OCaml, RPC	xapi uses xenstore to configure domains and some guests use xenstore to signal back a limited amount of information (e.g. OS version, IP address). These xenstore protocols are low-level, ad-hoc and very error-prone. Extending them for new applications is very tedious. A lot of the time we only want something a bit more like a procedure call (e.g. "ask the guest to execute this script"). It would be great if it were possible to register an RPC server skeleton inside the guest and associate it with a named function and then call it via the XenAPI. For some of the ad-hoc stuff have a look in xen-api.hg and ocaml/xenops/device.ml
Improve SR-IOV support	XCP	jonathan.ludlam AT eu.citrix.com	Medium, Ocaml, Design	Hardware that supports SRIOV is now becoming available on server class machines, and Xen already has support for this. Xapi also has been seen to support this, but only as a prototype - with the metrics code being particularly fragile. The code for this prototype is available, but it is crude and makes some assumptions about the internal state of the guest. A better design needs to be made, which might involve modifications to the guest agent, and then the design needs to be implemented. The project requires testing and working with the prototype and creating a design, re-architecting of the prototype which improves stability.

Other project ideas

If you have are interested in GSoC and none of the ideas above appeals to you, you can do one of the following:

• Check out the XCP Wishlist
• Check out last years GSoC ideas at XAPI project suggestions
• Or get in touch with community.manager@xen.org , who can then connect you to a potential mentor