https://wiki.xenproject.org/api.php?action=feedcontributions&user=Amirmc&feedformat=atomXen - User contributions [en]2024-03-28T15:02:47ZUser contributionsMediaWiki 1.31.3https://wiki.xenproject.org/index.php?title=MirageOS&diff=16259MirageOS2016-01-20T08:44:42Z<p>Amirmc: </p>
<hr />
<div>'''MirageOS''' is a library operating system that constructs [[unikernels]] for secure, high-performance network applications across a variety of cloud computing and mobile platforms.<br />
<br />
MirageOS applications are written in [[:Category:OCaml|OCaml]] and compiled into a complete image that can be run on Xen. The libraries include a network stack, http, and a complete SSL library, and Irmin, a distributed git-like data store.<br />
<br />
MirageOS is an official Xen Project [[Mirage Incubation Project Proposal|incubator project]].<br />
<br />
Code is released under the ISC license, with some code released under LGPLv2.<br />
<br />
==Resources==<br />
<br />
* The primary website is [https://mirage.io mirage.io].<br />
* Developer information can also be found at [[:Category:Mirage|Mirage page index]]<br />
* Source code is on [https://github.com/mirage github]. <br />
<br />
<br />
[[Category:Unikernels]]<br />
[[Category:Mirage]]<br />
[[Category:OCaml]]</div>Amirmchttps://wiki.xenproject.org/index.php?title=Category:Mirage_Devel&diff=14985Category:Mirage Devel2015-06-05T15:27:35Z<p>Amirmc: typo?</p>
<hr />
<div>{{Trailbox|MirageOS Developer Docs|<br />
|{{Trail|MirageOS Project|<br />
* [http://xenproject.org/developers/teams/mirage-os.html Project Portal]<br />
* [[Compile_Mirage|Compile MirageOS]]<br />
}}|{{Trail|Designs|<br />
* [[Mirage architecture|MirageOS architecture]]<br />
* [http://www.openmirage.org/wiki/tutorial-lwt Getting started with Lwt threads]<br />
* [http://www.openmirage.org/wiki/xen-synthesize-virtual-disk Synthesising virtual disks]<br />
}}|{{Trail|Proposals|<br />
* [[Mirage_split_netfront|Make xen netfront/netback standalone]]<br />
* [[Mirage_remove_xenstore_from_core|Remove dependency on xenstore in mirage-platform]]<br />
}}|{{Trail|Previews|<br />
* [[Mirage_dp1|Mirage developer preview 1]]<br />
}}<br />
}}<br />
<br />
[[Category:Mirage]]</div>Amirmchttps://wiki.xenproject.org/index.php?title=Category:Mirage_Devel&diff=14984Category:Mirage Devel2015-06-05T15:26:54Z<p>Amirmc: Change names to MirageOS</p>
<hr />
<div>{{Trailbox|MirageOS Developer Docs|<br />
|{{Trail|MirageOS Project|<br />
* [http://xenproject.org/developers/teams/mirage-os.html Project Portal]<br />
* [[Compile_Mirage|Compile MirageOS]]<br />
}}|{{Trail|Designs|<br />
* [[MirageOS architecture|Mirage architecture]]<br />
* [http://www.openmirage.org/wiki/tutorial-lwt Getting started with Lwt threads]<br />
* [http://www.openmirage.org/wiki/xen-synthesize-virtual-disk Synthesising virtual disks]<br />
}}|{{Trail|Proposals|<br />
* [[Mirage_split_netfront|Make xen netfront/netback standalone]]<br />
* [[Mirage_remove_xenstore_from_core|Remove dependency on xenstore in mirage-platform]]<br />
}}|{{Trail|Previews|<br />
* [[Mirage_dp1|Mirage developer preview 1]]<br />
}}<br />
}}<br />
<br />
[[Category:Mirage]]</div>Amirmchttps://wiki.xenproject.org/index.php?title=Main_Page&diff=14983Main Page2015-06-05T15:25:31Z<p>Amirmc: Mirage OS -> MirageOS</p>
<hr />
<div><!--{{InfoLeft|TODAY, Wednesday, May 27, is [[Xen Project Document Days|Document Day]]!}}--><br />
<!-- {{InfoLeft|December 17 is the [[Xen Project Test Days|Xen Project Test Day]] for [[Xen 4.5 RC4 test instructions|Xen Project 4.5 RC4]]}} --><br />
{{InfoLeft|Latest News: '''Xen 4.5''' has been released: [https://blog.xenproject.org/2015/01/13/less-is-more-in-the-new-xen-project-4-5-release release blog post], [http://xenproject.org/about/in-the-news.html press release], [[:Category:Xen_4.5|docs]] & [http://xenproject.org/downloads/xen-archives/xen-45-series-1/xen-450-1.html downloads]}} <br />
----<br />
The Xen Project wiki is a support and documentation resource for the Xen Project community. It is editable by community members and we [[Help:Contents|need your contributions to make it better]].<br />
{{WarningLeft|The Xen Project Wiki has been subject to sustained severe spam attacks in the last few years. To solve this and keep the wiki usable for everyone, we had to lock down the wiki and create an editors group. CAPTCHAs do not appear to work against the spam attacks we have seen. Until we have a solution in place, please [http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html fill out this form] (note: does not work in China) and we will add you to the editors group. If you can't access the form, please send an email to community.manager dot xenproject.org requesting that you need wiki access - please provide your wiki user name.}}<br />
----<br />
__NOTOC__<br />
{{Trailbox|Get started with the Xen Project Hypervisor|Xen_Started<br />
|{{Trail|Hypervisor Information|<br />
* [[Xen_Overview|Overview]] <br />
* [[Getting Started|Getting Started]]<br />
* [[Xen_Project_Release_Features|Features]]<br />
* [[:Category:Compatibility|Compatibility]] <br />
* [[Xen_/_XCP_/_XAPI_Overview|Xen/XCP/XAPI Comparison]]<br />
<!--* [[Video:_Introduction_to_Virtualization_Xen,_XCP,_and_the_Cloud|Video Tutorial]]--><br />
* [http://www.xenproject.org/help/presentations-and-videos/category/latest/xen-videos.html Video Library]<br />
* [http://www.xenproject.org/help/presentations-and-videos/category/latest/xen-presentations.html Presentation Library]<br />
}}|{{Trail|Hypervisor Docs|<br />
* [[Xen Project Beginners Guide|Beginners Guide]]<br />
* [[:Category:Manual|Manuals]]<br />
* [[:Category:Integration|Integrations]]<br />
* [[:Category:FAQ|FAQs]] & [[:Category:HowTo|HowTos]]<br />
* [[XenCommonProblems|General Problems]]<br />
* [[Xen Project Best Practices|Best Practices]]<br />
* [[Books#Xen|Books]]<br />
}}|{{Trail|Get Help!|<br />
* Getting help via [http://www.xenproject.org/help/mailing-list.html Mailing Lists] or [http://www.xenproject.org/help/questions-and-answers.html Q&A] <br />
* [http://www.xenproject.org/directory/directory.html Get paid help]<br />
* [[Reporting_Bugs_against_Xen|Reporting Bugs]]<br />
* [http://xenorg.uservoice.com Suggest/vote on future features] <br />
}}|{{Trail|Announcements|<br />
* [[Security_Announcements|Security Announcements]]<br />
* [http://blog.xenproject.org/ Our Blog]<br />
* [http://xenproject.org/about/in-the-news.html Press Releases]<br />
}}<br />
}}<br />
<br />
<!-- ARCHIVED...<br />
{{Trailbox|Get started with XCP|XCP_Started<br />
|{{Trail|XCP Information|<br />
* [[XCP_Overview|XCP Overview]] <br />
* [http://www.xenproject.org/downloads/xen-cloud-platform-archives.html XCP Downloads]<br />
* [[XCP_Management_Tools|XCP Management Tools]]<br />
* [[XCP_Release_Features|XCP Features]]<br />
* [[Xen_/_XCP_/_XCP_on_Linux_Overview|XCP/Xen Comparison]]<br />
* [[XCP/XenServer Feature Matrix|XCP/XenServer Comparison]]<br />
* [[XCP_Roadmap|XCP Roadmap]]<br />
* [[XCP Release History|XCP Release History]]<br />
}}<br />
|{{Trail|XCP Docs|<br />
* [[XCP Beginners Guide]]<br />
* [[:Category:Manual#XCP|XCP Manuals]]<br />
* [[XCP_FAQ_General|XCP FAQ]]<br />
* [[XCP_HowTo|XCP HowTos]]<br />
* [[XAPI_on_Ubuntu|XCP on Debian/Ubuntu]]<br />
* [[XCP_Overview_for_Developers|XCP Overview for Devs]]<br />
* [[Books#XCP|XCP Books]]<br />
}}<br />
|{{Trail|Get Help with XCP!|<br />
* [http://www.xenproject.org/developers/teams/xapi.html Getting help!] <br />
* [http://www.xenproject.org/directory/directory.html Get paid help!] <br />
* [[Reporting_Bugs_against_XCP|Reporting Bugs]]<br />
* [http://xenorg.uservoice.com Suggest/vote on future XCP features!] <br />
}}<br />
}}<br />
--><br />
{{Trailbox|Get involved|Community<br />
|{{Trail|Users and Easy Tasks|<br />
* [[Xen_Project_Swag|Ideas for T_Shirts, etc.]] <br />
----<br />
* [[Xen_Project_Document_Days|Xen Project Document Days]]<br />
* [[Xen_Project_Test_Days|Xen Project Test Days]]<br />
* [[Xen_Mailing_List_Moderators|Help Moderate a List]]<br />
* [[Help:Contents#How_you_can_help|Help us improve the Wiki]]<br />
* [[Wiki_Community|Help Maintain the Wiki]]<br />
----<br />
* [[Acknowledgements]]<br />
}}|{{Trail|Development<br>(all subprojects)|<br />
* [[Hackathon/April2015|Hackathon Intel Shanghai, April 29-30]]<br />
* [[Hackathon|Hackathons & Dev Meetings]] <br />
* [[GSoC_2015|GSoc 2015]] <br />
* [[Outreachy/Round10]]<br />
}}<br>{{Trail|Project Proposals|<br />
* [[Windows PV Drivers Incubation Project Proposal]]<br />
* [[Embedded and Automotive PV Drivers Project Proposal]]<br />
}}<br>{{Trail|Vendors|<br />
* [[Xen Project Ecosystem Directory|Ecosystem Directory]]<br />
* [[Xen Project Job Listings|Job Listings]]<br />
}}|{{Trail|Hypervisor Development|<br />
* [[Xen_Project_Hypervisor_Roadmap/4.6|4.6 Roadmap]]<br />
* [[Xen Repositories|Source Code Repositories]]<br />
* [[Submitting Xen Project Patches|Submitting Patches]]<br />
* [[Reporting Bugs against Xen Project|Reporting Bugs]]<br />
* [[Xen Development Projects|Xen Development Projects]]<br />
}}<br>{{Trail|Mirage OS Development|<br />
* [[:Category:Mirage Devel|MirageOS Development]]<br />
* [[Unikernels|Unikernels (Cloud Operating Systems)]]<br />
}}<br>{{Trail|XAPI Development|<br />
* [[:Category:XAPI Devel|XAPI Development]]<br />
}}|{{Trail|Upstream/downstream|<br />
* [[Distros|Information for Maintainers of distro packages]]<br />
* [[Security_Announcements|Security Announcements]]<br />
}}<br />
|{{Trail|Wiki|<br />
* [[Special:UserLogin|Create an account or log in]]<br />
* [[Help:Set_up_Search_Correctly|Set up Search correctly!]]<br />
* [http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html Become an editor]<br />
* [[Help:Contents|Read the Wiki Guide]]<br />
* [[Sandbox|Play with the Sandbox]]<br />
}}<br>{{Trail|MediaWiki|<br />
* [http://upload.wikimedia.org/wikipedia/commons/8/89/Cheatsheet-mediawiki.pdf MediaWiki Cheat Sheet]<br />
* [http://www.mediawiki.org/wiki/Help:Formatting MediaWiki Markup]<br />
* [http://www.mediawiki.org/wiki/Help:Contents MediaWiki Help Contents]<br />
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]<br />
* [http://www.mediawiki.org/wiki/Books_about_MediaWiki Books about MediaWiki]<br />
}}<br />
}}<br />
<br />
<br />
{{InfoLeft|Note: Documentation about XCP is now hosted on [http://wiki.XenServer.org/Category:XCP wiki.XenServer.org].}}<br />
<br />
[[Category:Index]]<br />
{{Languages}}</div>Amirmchttps://wiki.xenproject.org/index.php?title=Unikernels&diff=14981Unikernels2015-06-04T22:53:46Z<p>Amirmc: Boxfuse isn't a unikernel in the sense that the others are (single-address space, library OS). Hence doesn't belong on this list.</p>
<hr />
<div>Xen Project has been at the forefront of the birth of Unikernels (or Cloud Operating Systems): specialized lightweight operating systems which are only intended to be used within a Virtual Machine. These Unikernels may become the core of a new form of cloud, where a single hypervisor instance can support hundreds or even thousands of VMs.<br />
<br />
== What is a Unikernel? ==<br />
Normally, a hypervisor loads a Virtual Machine with a fully functional operating system, like some flavor of Linux, Windows, or one of the BSDs. These operating systems were designed to be run on hardware, so they have all the complexity needed for a variety of hardware drivers from an assortment of vendors with different design concepts. These operating systems are also intended to be multi-user, multi-process, and multi-purpose. They are designed to be everything for everyone, so they are necessarily complex and large.<br />
<br />
A Unikernel, on the other hand, is (generally) single-purpose. It is not designed to run on hardware, and so lacks the bloat and complexity of drivers. It is not meant to be multi-user or multi-process, so it can focus on creating a single thread of code which runs one application, and one application only. Most are not multi-purpose, as the target is to create a single payload that a particular instance will execute (OSv is an exception). Thanks to this single-minded design, the Unikernel is small, lightweight, and quick.<br />
<br />
== What do Unikernels Provide? ==<br />
Unikernels normally generate a singular runtime environment meant to enable single applications built solely with that environment. Generally, this environment lacks the ability to spawn subprocesses, execute shell commands, create multiple threads, or fork processes. Instead, they provide a pure incarnation of the language runtime targetted, be it OCaml, Haskell, Java, Erlang, or some other environment.<br />
<br />
== Unikernels Versus Linux Containers ==<br />
Much has been made recently of the advantages of Linux Container solutions over traditional VMs. It is said by container advocates that their lightweight memory footprint, quick boot time, and ease of packaging makes containers the future of virtualization. While these aspects of containers are certainly notable, they do not spell the end of the world of the hypervisor. In fact, Unikernels may reduce the long-term usefulness of containers.<br />
<br />
Unikernels facilitate the very same desirable attributes described by the container proponents, with the addition of an absolutely splendid security story which few other solutions can match.<br />
<br />
== What About Security? ==<br />
Unikernels offer an excellent security scenario. The attack surface for these instances are quite small, as they lack the variety of functions (and, therefore, the potential flaws to be exploited) provided by standard operating systems, as well as the tools used to exploit them (there are no shells, no utilities, and no variety of programs to be leveraged if a flaw is located). Because of the design of Unikernels, it is hard to find security flaws, and even harder to find ways to exploit them.<br />
<br />
Furthermore, many Unikernels (OSv is an exception to this) are used to compile their payloads. Rather than having a uniform operating layer which is the same for each application stack, most unikernels actually compile into the application layer, resulting in an optimized piece of code which provides exactly what the application needs in a unique footprint. This means that the attack surface on, say, a Mirage OS webserver will not be the same as that of a Mirage OS DNS server. Each operating layer will be unique, meaning that the attack surfaces of the operating layer will be different for each. An operating layer exploit which might penetrate one may not be successful at all on the other. This increases security tremendously by design.<br />
<br />
== How do Unikernels Interact with Xen Project? ==<br />
Being Open Source, Xen Project can both create its own Unikernel and leverage those developed by others. In fact, Xen Project runs the gamut, as it works on its own Unikernel (MirageOS), is the target engine for some others (like LING), and can use entirely separate efforts (like HaLVM or OSv).<br />
<br />
In addition, Xen Project has taken a proactive position in enabling the use of Unikernels. An example of this is the "3000 Domains" experiment, in which large numbers of VMs were attempted to be loaded on a single hypervisor host. As a result, modifications were made to the hypervisor code base to enable this concept. Watch the [http://xenproject.org/presentations-and-videos/video/the-3000-domains-experiment.html Video].<br />
<br />
== Unikernel List ==<br />
The following Unikernels are currently of interest to the Xen Project (though the list is not exhaustive):<br />
<br />
* [http://www.openmirage.org/ MirageOS], an official [http://xenproject.org/developers/teams/mirage-os.html incubator effort] of Xen Project, employs an OCaml-based kernel. See the [http://www.slideshare.net/xen_com_mgr/mirage-extreme-specialization-of-cloud-appliances Presentation] as well as the [[Mirage_architecture]] page. Also, see the documents from the [[:Category:Mirage|Mirage Category]].<br />
* [http://erlangonxen.org/ LING (formerly Erlang on Xen)] creates an Erlang runtime environment. See the [http://www.slideshare.net/vsovietov/erlang-dnipro-2014-erlangonxen Presentation].<br />
* [https://github.com/GaloisInc/HaLVM#readme HaLVM], the Haskell Lightweight Virtual Machine from [http://corp.galois.com/halvm Galois], allows you to run Haskell programs. See the [http://www.slideshare.net/xen_com_mgr/the-halvm-a-simple-platform-for-simple-platforms Presentation].<br />
* [http://osv.io/ OSv] from [http://www.cloudius-systems.com/ Cloudius Systems] produces a Java environment. See the [http://www.slideshare.net/dmarti1111/o-sv-linux-collaboration-summit Presentation].<br />
* [https://cnp.neclab.eu/clickos/ ClickOS] from [https://cnp.neclab.eu/ NEC labs] a high-performance unikernel producing network devices. See [https://cnp.neclab.eu/clickos/ their webpage].<br />
* [http://rumpkernel.org Rumpkernels] from [http://netbsd.org the NetBSD community] provide a small platform with driver support as the base for unikernel work. See [https://github.com/rumpkernel/wiki/wiki/Info%3A-Comparison-of-rump-kernels-with-similar-technologies their write-up on how it compares to other Unikernels].<br />
<br />
<br />
Because of the dynamic state of this technology, this list will likely be in constant flux for the next few years.<br />
<br />
[[Category:Beginners]]<br />
[[Category:Cloud]]<br />
[[Category:Mirage]]<br />
[[Category:OCaml]]<br />
[[Category:Fundamentals]]<br />
[[Category:Integration]]</div>Amirmchttps://wiki.xenproject.org/index.php?title=Archived/Outreachy/Round10&diff=14576Archived/Outreachy/Round102015-03-18T00:16:04Z<p>Amirmc: Mirage OS -> MirageOS</p>
<hr />
<div>= Xen Project and Outreachy =<br />
<!-- [[File:opw-poster-2014-May-August.png|right|border|400px]]--><br />
The Xen Project Advisory Board will be sponsoring two interns for '''Round 10''' of [https://wiki.gnome.org/Outreachy Outreachy] (formerly known as the GNOME Outreach Program) which runs from May 25, 2015 to August 25, 2015. Outreachy helps people from groups underrepresented in free and open source software get involved. Our goal is to increase the participation of underrepresented groups in the Xen Project. It is an expansion of the very successful GNOME Outreach Program for Women and we are running the program in conjunction with GNOME and other prominent open source projects.<br />
<br />
= Information For Applicants =<br />
== How To Apply ==<br />
The official application period for Outreachy Round 10 begins February 17. Please fill our your [https://wiki.gnome.org/Outreachy#Submit_an_Application application] and complete your Xen Project patch by March 24. Applicants that do not complete the first patch will not be considered for an internship. Please take a look at our [[Outreachy/Apply|application FAQ]] for more info on how to fill our your initial application. Applicants will be notified in April if they have been accepted.<br />
<br />
If you are interested in being a Xen Project intern, please:<br />
<br />
* Join the [http://www.xenproject.org/help/mailing-list.html xen-devel] mailing list. Depending on the project you choose, you may also need to join <em>xen-api</em> or <em>mirageos-devel@lists.xenproject.org</em> (do check the information in the project). Check the [http://www.xenproject.org/help/mailing-list.html list directory].<br />
* Join the #opw IRC channel on irc.gnome.org<br />
* Join the #xen-opw IRC channel on irc.freenode.net<br />
* Read our [[Outreachy/Apply|instructions for applying]], and apply by March 24.<br />
* Ask one of our friendly developers on for a bite size bug or work item. This can be reviewing somebody's code, submitting a patch, or similar and will need to be done by March 24.<br />
<br />
== Community Reviewed Project List ==<br />
<br />
For a list of project ideas see, [[Outreach Program Projects]] or [[Xen_Development_Projects|General List of Development Projects]] or [https://github.com/mirage/mirage-www/wiki/Pioneer-Projects MirageOS Pioneer Projects]<br />
<br />
== Useful Resources ==<br />
<br />
Here is some links to guides, tools, development flows etc.<br />
<br />
* [[:Category:Developers|All Developer Information]]<br />
* [[Xen_Overview|Xen Project Overview]]<br />
* [[Submitting Xen Patches with Git]]<br />
* [[Xen Beginners Guide]]<br />
* [http://git-scm.com/documentation Introduction to Git]<br />
<br />
= Information For Mentors =<br />
Please review the mentor information [https://wiki.gnome.org/Outreachy/Admin/InfoForMentors here]<br />
<br />
<!-- Round 8 data; replace with Round 9 when available<br />
= Accepted Projects =<br />
<br />
{{project<br />
|Project=Improvements to the block I/O paravirtualized Xen drivers<br />
|Date=21/04/2014<br />
|Contact=Mentor: Konrad Rzeszutek Wilk, Intern: Arianna Avanzini<br />
|Desc= See [https://docs.google.com/document/d/16W9RkaZBBqKVoHJjTYhAEzPAtKnqes_wlrp6QJqloKs/edit?usp=sharing here]<br />
}}<br />
<br />
{{project<br />
|Project=MirageOS contributions and improvements<br />
|Date=21/04/2014<br />
|Contact=Mentor: Richard Mortier, Intern: Mindy Preston<br />
|Desc=1 booting on the myriad cloud providers remains a total pain, so figuring out how to create one command that takes some credentials and gets a unikernel started on rackspace/amazon/openstack would be very handy. There's also cloud-init to look at. <br />
<br />
2 protocol bisimulations against existing implementations: for a number of our libraries, we'd like a way to test our protocol code against standard implementations and verify that they are functionally equivalent. In certain cases, we will of course know that they are not, so we should be able to mark those as TODOs in our code. Good protocol testing choices: the TCP/IP stack vs Linux, the Cohttp web stack vs Nginx/Apache, the emerging SSL stack vs OpenSSL (important!) <br />
<br />
3 new functionality: adding IPv6 support into mirage-net would be fairly straightforward and rather useful. Multipath TCP and/or TCPcrypt are more difficult but in scope.<br />
<br />
4 If you feel like low-level hackery, porting Xen MiniOS to ARM would be a difficult but exceedinly rewarding project, as Mirage would then run on embedded devices like the Cubieboard2. This is a kernel hacking heavy project.<br />
<br />
5 you could also pen test the heck out of the libraries to find and fix denial of services (e.g. unbounded reads in Cohttp for long headers, that sort of thing). We know of quite a few, but a structured set of attacks would help keep them out.<br />
}}<br />
--><br />
<br />
[[Category:Community]]<br />
[[Category:OPW]]<br />
[[Category:Outreachy_Round10]]</div>Amirmchttps://wiki.xenproject.org/index.php?title=Archived/GSoC_2015&diff=14201Archived/GSoC 20152015-02-09T15:35:01Z<p>Amirmc: typo</p>
<hr />
<div>{{InfoLeft|Please read this [http://lists.xen.org/archives/html/xen-devel/2015-02/msg00902.html message] if you are a mentor to and want to prepare for GSoC 2015}}<br />
<br />
__TOC__<br />
<br />
http://1-ps.googleusercontent.com/xk/lUi00NOiZZtaYcm5-HDw_Ypz0k/s.google-melange.appspot.com/www.google-melange.com/soc/content/2-1-20150205/images/gsoc/logo/banner-gsoc2015.png.pagespeed.ce.1-XG35qq3RLrLftld3Q2.png<br />
<br />
== Xen Project ==<br />
<br />
The Xen Project is a Linux Foundation collaborative project that develops the <br />
* [http://xenproject.org/developers/teams/pvops.html Xen related enablers in Linux (PVOPS)]<br />
* [http://xenproject.org/developers/teams/hypervisor.html Xen Hypervisor] (for x86 and [http://xenproject.org/developers/teams/arm-hypervisor.html ARM])<br />
* [http://xenproject.org/developers/teams/xapi.html The XAPI toolstack]<br />
* [http://xenproject.org/developers/teams/mirage-os.html Mirage OS]<br />
* [http://xenproject.org/developers/teams/windows-pv-drivers.html Windows PV Drivers]<br />
* [http://xenproject.org/developers/teams/embedded-and-automotive.html Embedded & Automotive Drivers] <br />
The project also has excellent relationships with its upstreams (Linux Kernel, the BSDs, QEMU and other projects) and upstreams such as Linux distributions. This is reflected in the project list, which contains many interesting cross-project development projects for students.<br />
<br />
== GSoC and Xen Project ==<br />
This page is used to list project ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code (GSOC) 2015]. <br />
<br />
=== Key GSoC resources ===<br />
The Xen Project is planning to apply as a Mentoring Organization. Stay posted.<br />
<br />
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 GSoC Homepage]<br />
* [http://xenproject.org/help/presentations-and-videos/video/xpds14v-panel.html Video with some of our GSoC 2014 participants discussing their experience]<br />
<br />
=== Finding a project that fits you ===<br />
This page lists Xen Project development projects for GSoC that can be picked up by anyone! If you're interesting in hacking Xen Project code and want to become a part of our friendly developer community this is the place to start! Ready for the challenge?<br />
<br />
'''To work on a project:'''<br />
* Find a project that looks interesting (or a bug if you want to start with something simple)<br />
* Send an email to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] (see '''Developer Mailing Lists''') and let us know if you are interested in starting to work or applying on a specific project.<br />
* Post your ideas, questions, RFCs to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] sooner than later so you can get comments and feedback. <br />
<br />
'''You have your own project idea: no problem!'''<br />
* If you have your own project idea, outline what you are trying to do on the mailing list. If you know the right list, post your project idea on [http://www.xenproject.org/help/mailing-list.html mailing list]. Failing that post on xen-devel and we can redirect you to the right list. Make sure you add '''GSoC 2015''' to the subject line.<br />
<br />
'''It is a good idea to ...'''<br><br />
The Xen Project has also participated in the Gnome Outreach Program for Women (OPW) in the past. One of the things we learned by participating in OPW is that you will be more successful, happier and get more out of participating in student programs such as GSoC, if you do a bit of prep-work before writing an application. Here is some stuff you can do:<br />
* Contact your mentor early and get to know him or her<br />
* If the Xen Project is accepted into GSoC, start hanging out on our IRC channel. You can use the #xen-opw IRC channel on freenode.net for now (if accepted, we will create a GSoC channel)<br />
* You may want to ask the mentor for a couple of small bitesize work-items (such as reviewing someones patch, a bitesize bug, ...) and start communicating on the relevant [http://www.xenproject.org/help/mailing-list.html mailing list]. That helps you become familiar with our development process, the mentor and other community members and will help you chose the right project and help you decide whether the Xen project is for you.<br />
* Note that quite a few Xen maintainers used to be GSoC students once. Feel free to ask community dot manager at xenproject dot org to put you in touch with them if you have questions about their experience.<br />
* Any work you submit before applying for a project should be based on xen-unstable development tree, if the project is Xen Hypervisor and/or tools related. Linux kernel related patches should be based on upstream kernel.org Linux git tree (latest version). XAPI and Mirage OS patches should be based on the right codeline too. Check out the '''navigation by audience''' section on the left to find resources.<br />
<br />
==== More resources ====<br />
Quick links to changelogs of the various Xen related repositories/trees: Please see [[XenRepositories]] wiki page!<br />
<br />
Before to submit patches, please look at [[Submitting Xen Patches]] wiki page and the relevant [http://www.xenproject.org/developers/teams.html Xen Project team page]. This will contain more information.<br />
<br />
If you have new ideas, suggestions or development plans let us know and we'll update this list!<br />
<br />
=== Aspiring Students ===<br />
* Please contact the mentor and CC the most appropriate mailing list<br />
* Get a bite-size task from the mentor before the application starts<br />
* If you feel comfortable with an idea, please put your name to an idea using the following format<br />
<pre><br />
{{project<br />
...<br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} I am interested in this idea ... <br />
(note that you may also want to link to the e-mail thread with the mentor)<br />
</pre><br />
* You will need to request write access to the wiki by filling out [http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html this form]<br />
<br />
=== Applying for GSoC ===<br />
{{InfoLeft|Note that we will update this section when more student information on [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 melange] is available, to make it easier for you to find information. And of course assuming that the Xen Project will be accepted into GSoC.}}<br />
<br />
To apply for a project, follow the steps outlined on<br />
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 melange]<br />
* We do have our own [[GSoC Student Application Template]] form<br />
<br />
== List of peer reviewed Projects ==<br />
=== Domain support (PVOPS and Linux) ===<br />
<br />
{{project<br />
|Project=Utilize Intel QuickData on network and block path.<br />
|Date=01/22/2013<br />
|Difficulty=High<br />
|Contact=Konrad Rzeszutek Wilk <konrad.wilk@oracle.com><br />
|Desc=The Intel QuickData, also known as Direct Cache Access (or IOA/T), is the chipset that sits in the PCIe subsystem in the Intel systems. It allows the PCIe subsystem to tag which PCIe writes to memory should reside in the Last Level Cache (LLC, also known as L3, which in some cases can be of 15MB or 2.5MB per CPU). This offers incredible boosts of speed - as we bypass the DIMMs and instead the CPU can process the data in the cache.<br />
<br />
Adding this component in the network or block backends can mean that we can keep the data longer in the cache and the guest can process the data right off the cache.<br />
<br />
See these for references:<br />
http://www.intel.com/content/www/us/en/wireless-network/accel-technology.html<br />
http://www.intel.com/content/www/us/en/chipsets/quickdata-technology-software-guide-for-linux-paper.html<br />
<br />
Also the dmaengine@vger.kernel.org is an excellent mailing list to subscribe to.<br />
<br />
|Skills=The basic requirement for this project is Linux kernel programming skill.<br />
The candidate for this project should be familiar with open source development workflow as it may require collaboration with several parties.<br />
<br />
|Outcomes=Expected outcome:<br />
* Investigate whether DCA (aka QuickData aka I/O AT) works with Xen.<br />
* If above is true: have upstream patches (or draft patches)<br />
* and benchmark report of with and without.<br />
|GSoC=Yes<br />
}} <br />
<br />
{{project<br />
|Project=Xen block backend/frontend multiqueue support<br />
|Date=03/09/2014<br />
|Difficulty=High<br />
|Contact=Konrad Rzeszutek Wilk <konrad.wilk@oracle.com><br />
|Desc=<br />
The Linux kernel (and FreeBSD, Windows, etc) have ParaVirtualized (PV) drivers to perform<br />
the I/O instead of using the emulated devices that appear in QEMU (IDE, SCSI, etc). This is<br />
done because the emulation of the IDE drivers is quite slow - and if you dig in how it<br />
actually is done - it is full of bit-banging registers. The PV drivers are an answer to this<br />
and eliminate the need for emulation. The mechanism by which they work is <br />
nicely draw out in http://wiki.xen.org/wiki/PV_Protocol<br />
and http://www.informit.com/articles/article.aspx?p=1160234&seqNum=3<br />
("Definitive Guide to the Xen Hypervisor, The")<br />
<br />
There have been improvements done in it - see http://wiki.xen.org/wiki/Xen_4.3_Block_Protocol_Scalability<br />
and http://blog.xen.org/index.php/2013/08/07/indirect-descriptors-for-xen-pv-disks/<br />
<br />
However, there are still room for improvement. We can utilize the new<br />
block multiqueue API support in Linux (See https://lwn.net/Articles/552904/<br />
and http://kernel.dk/systor13-final18.pdf)<br />
to allocate per CPU a block thread (which handles the I/O transmission).<br />
<br />
That should provide greater throughput and lower latency for I/O workloads.<br />
<br />
Also see https://docs.google.com/document/d/1Vh5T8Z3Tx3sUEhVB0DnNDKBNiqB_ZA8Z5YVqAsCIjuI<br />
which has some of the explanation.<br />
<br />
| Skills=You need to have understanding of:<br />
* Knowledge of Linux kernel<br />
* How I/O works<br />
* C language<br />
|Outcomes=Expected outcome:<br />
* Patches for the Linux Kernel Mailing list (LKML).<br />
* Benchmark reports.<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Enabling the 9P File System transport as a paravirt device<br />
|Date=01/20/2014<br />
|Difficulty=High<br />
|Contact=Andres Lagar-Cavilla <andres@lagarcavilla.org><br />
|GSoC=Yes<br />
|Desc=VirtIO provides a 9P FS transport, which is essentially a paravirt file system device. VMs can mount arbitrary file system hierarchies exposed by the backend. The 9P FS specification has been around for a while, while the VirtIO transport is relatively new. The project would consist of implementing a classic Xen front/back pv driver pair to provide a transport for the 9P FS Protocol.<br />
<br />
* More info: http://www.linux-kvm.org/page/9p_virtio<br />
* Also the Bell Labs original OS that introduced the 9P protocol: http://plan9.bell-labs.com/sources/plan9/sys/src/<br />
<br />
|Skills= Required skills include knowledge of kernel hacking, file system internals. Desired skills include: understanding of Xen PV driver structure, and VirtIO.<br />
<br />
|Outcomes=Expected outcome:<br />
* LKML patches for front and back end drivers. <br />
* In particular, domain should be able to boot from the 9P FS.<br />
|Review=(delete as addressed)<br />
* {{Comment|[[User:Lars.kurth|Lars.kurth]] 15:24, 17 February 2014 (UTC):}} This project would benefit from links to the virtio specs and documents explaining how the PV protocol works.<br />
}}<br />
<br />
=== Xen Hypervisor Userspace Tools ===<br />
<br />
{{project<br />
|Project=CPU/RAM/PCI diagram tool<br />
|Date=01/30/2014<br />
|Contact=Andrew Cooper <andrew.cooper3@citrix.com><br />
|Difficulty=Moderate, to Extremely Difficult (depending on which area of the problem you choose to tackle)<br />
|Skills=Understanding of PC server hardware, Understanding of ACPI/SMBios tables, Linux scripting or kernel hacking (depending on which area of the problem you choose to tackle)<br />
|Desc=It is often useful in debugging kernel, hypervisor or performance problems to understand the bus topology of a server. This project will create a layout diagram for a server automatically using data from ACPI Tables, SMBios Tables, lspci output etc. This tool would be useful in general Linux environments including Xen and KVM based virtualisation systems.<br />
<br />
There are many avenues for extension such as labelling relevant hardware errata, performing bus throughput calculations etc.<br />
|Outcomes=A tool is created that can either run on a live Linux system or offline using captured data to produce a graphical representation of the hardware topology of the system including bus topology, hardware device locations, memory bank locations, etc. The tool would be submitted to a suitable open-source project such as the Xen hypervisor project or XCP.<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=KDD (Windows Debugger Stub) enhancements<br />
|Date=01/30/2014<br />
|Contact=Paul Durrant <paul.durrant@citrix.com><br />
|Difficulty=Medium<br />
|Skills=C, Kernel Debuggers, Xen, Windows<br />
|Desc=kdd is a Windows Debugger Stub for Xen hypervisor. It is OSS found under http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/debugger/kdd;h=fd82789a678fb8060cc74ebbe0a04dc58309d6d7;hb=refs/heads/master<br />
kdd allows you to debug a running Windows virtual machine on Xen using standard Windows kernel debugging tools like WinDbg. kdd is an external debugger stub for the windows kernel. <br />
Windows can be debugged without enabling the debugger stub inside windows kernel by using kdd. This is important for debugging hard to reproduce problems on Windows virtual machines that may not have debugging enabled.<br />
<br />
Expected Results:<br />
# Add support for Windows 8 (x86, x64) to kdd<br />
# Add support for Windows Server 2012 to kdd<br />
# Enhance kdd to allow WinDbg to write out usable Windows memory dumps (via .dump debugger extension) for all supported versions<br />
# Produce a user guide for kdd on Xen wiki page<br />
<br />
Nice to have: Allow kdd to operate on a Windows domain checkpoint file (output of xl save for e.g.)<br />
|Outcomes=Code is submitted to xen-devel@xen.org for inclusion in the xen-unstable project.<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=CPUID Programming for Humans<br />
|Date=02/04/2014<br />
|Contact=Andres Lagar-Cavilla <andres@lagarcavilla.org><br />
|Difficulty=Easy<br />
|GSoC=Yes<br />
|Desc=When creating a VM, a policy is applied to mask certain CPUID features. Right now it's black magic.<br />
<br />
The KVM stack has done an excellent job of making this human-useable, and understandable.<br />
<br />
For example, in a qemu-kvm command-line you may encounter:<br />
<pre><br />
-cpu SandyBridge,+pdpe1gb,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,<br />
+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme<br />
</pre><br />
<br />
And in <qemu>/target-i386.c you find a fairly comprehensive description of x86 processor models, what CPUID features are inherent, and what CPUID feature each of these symbolic flags enables.<br />
<br />
In the Xen world, there is a libxc interface to do the same, although it's all hex and register driven. It's effective, yet horrible to use.<br />
<br />
An ideal outcome would have libxl config files and command line absorb a similarly human-friendly description of the CPUID features a user wishes for the VM, and interface appropriately with libxl. Further, autodetection of best CPUID shuold yield a human-readable output to be able to easily understand what the VM thinks about its processor.<br />
<br />
Finally, interfacing with libvirt should be carefully considered.<br />
<br />
CPUID management is crucial in a heterogeneous cluster where migrations and save restore require careful processor feature selection to avoid blow-ups.<br />
<br />
See: <br />
* http://wiki.qemu.org/images/c/c8/Cpu-models-and-libvirt-devconf-2014.pdf<br />
* https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/<br />
* http://blog.xen.org/index.php/2014/01/17/libvirt-support-for-xens-new-libxenlight-toolstack/<br />
|Skills= A good understanding of C user-land programming, and the ability to dive into qemu/libvirt (for reference code and integration), as well as libxc and libxl (for implementation).<br />
<br />
|Outcomes=Expected outcome:<br />
* Mainline patches for libxl<br />
}}<br />
<br />
{{project<br />
|Project=Rump kernel based stubdom<br />
|Date=Feb 06 2014<br />
|Verified=Feb 06 2014<br />
|Contact=Wei Liu <wei.liu2@citrix.com><br />
|Difficulty=Easy<br />
|GSoC=Yes<br />
|Desc=Stubdom can help boost performance and security. Currently stubdom is not very nice to work with. It employs an ancient version of newlib and the build system is fragile.<br />
<br />
Rump kernel (a way to implement unikernel / library OS) already runs on Xen and it uses NetBSD's libraries which are much more maintainable. This project aims to port existing stubdoms (c, xenstore, ocaml etc) to rump kernel.<br />
<br />
During this process, student can get first hand experience on Xen and rump kernel and tackle both kernel level and application level problems. The experience on the frontier of OS development and research is also valuable. Student should be able to understand how a to turn a piece of software into unikernel when he / she finishes this project.<br />
<br />
Useful links:<br />
<br />
* http://rumpkernel.org/<br />
<br />
|Skills= Knowledge of operating system, GNU autotools, C programming and good debugging skills.<br />
<br />
|Outcomes=Patches for Xen and rump kernel.<br />
}}<br />
<br />
=== MirageOS ===<br />
<br />
{{project<br />
|Project=Various MirageOS Pioneer Projects<br />
|Date=01/30/2015<br />
|Verified=Feb 8th, 2015 (see this [http://lists.xenproject.org/archives/html/mirageos-devel/2015-02/msg00046.html conversation])<br />
|Contact=Send a mail to mirageos-devel@lists.xenproject.org if you're interested in starting on one or several of these projects. <br />
|Difficulty=Various levels of difficulty<br />
|Skills=OCaml<br />
|Desc=This is a list of pioneer projects for Mirage OS, covering area such as '''Build Tools''', '''New Libraries''', '''Storage Technologies''', '''Networking Technologies''', '''Interfaces to Non-OCaml (aka foreign) Languages''' and other topics. Note that some of these projects may be too small or too big for a single GSoC project. If you are interested in one of these, make sure you discuss first on mirageos-devel@lists.xenproject.org - we can then merge or split these as needed for GSoC.<br />
<br />
References:<br />
* [https://github.com/mirage/mirage-www/wiki/Pioneer-Projects Complete list of Pioneer Projects]<br />
<br />
|GSoC=yes, but do check mirageos-devel@lists.xenproject.org first<br />
}}<br />
<br />
== List of projects that need more work ==<br />
{{Anchor|Unreviewed Project Ideas}}<br />
<br />
=== Xen Hypervisor ===<br />
<br />
{{project<br />
|Project=Introducing PowerClamp-like driver for Xen<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
PowerClamp was introduced to Linux in late 2012 in order to allow users to set a system-wide maximum<br />
power usage limit. This is particularly useful for data centers, where there may be a need to<br />
reduce power consumption based on availability of electricity or cooling. A [http://lwn.net/Articles/528124/ more complete writeup]<br />
is available at LWN.<br />
<br />
These same arguments apply to Xen. The purpose of this project would be to implement a similar functionality in Xen,<br />
and to make it interface as well as possible with the Linux PowerClamp tools, so that the same tools could be used<br />
for both. [[GSoC_2013#powerclamp-for-xen]]<br />
|GSoC=Yes<br />
}}<br />
<br />
=== Xen Hypervisor Userspace Tools ===<br />
{{project<br />
|Project=Refactor Linux hotplug scripts<br />
|Date=15/11/2012<br />
|Contact=Roger Pau Monné <[mailto:roger.pau@citrix.com roger.pau@citrix.com]><br />
|Desc=<br />
Current Linux hotplug scripts are all entangled, which makes them really difficult to understand or modify. The reason of hotplug scripts is to give end-users the chance to "easily" support different configuration for Xen devices.<br />
<br />
Linux hotplug scripts should be analized, providing a good description of what each hotplug script is doing. After this, scripts should be cleaned, putting common pieces of code in shared files across all scripts. A Coding style should be applied to all of them when the refactoring is finished.<br />
<br />
[[GSoC_2013#linux-hotplug-scripts]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=XL to XCP VM motion<br />
|Date=15/11/12<br />
|Contact=[mailto:ian.campbell@citrix.com Ian Campbell]<br />
|Desc=Currently [[XL|xl]] (the toolstack supplied alongside Xen) and [[XAPI|xapi]] (the XCP toolstack) have very different concepts about domain configuration, disk image storage etc. In the XCP model domain configuration is persistent and stored in a data base while under xl domain configuration is written in configuration files. Likewise disk images are stored as VDIs in Storage Repositories while under xl disk images are simply files or devices in the dom0 filesystem. For more information on xl see [[XL]]. For more information on XCP see [[XCP Overview]].<br />
<br />
This project is to produce one or more command-line tools which support migrating VMs between these toolstacks.<br />
<br />
One tool should be provided which takes an xl configuration file and details of an XCP pool. Using the XenAPI XML/RPC interface It should create a VM in the pool with a close approximation of the same configuration and stream the configured disk image into a selected Storage Repository.<br />
<br />
A second tool should be provided which performs the opposite operation, i.e. give a reference to a VM residing in an XCP pool it should produce an XL compatible configuration file and stream the disk image(s) our of Xapi into a suitable format.<br />
<br />
These tools could be reasonably bundled as part of either toolstack and by implication could be written in either C, Ocaml or some other suitable language.<br />
<br />
The tool need not operate on a live VM but that could be considered a stretch goal.<br />
<br />
An acceptable alternative to the proposed implementation would be to implement a tool which converts between a commonly used VM container format which is supported by XCP (perhaps [http://en.wikipedia.org/wiki/Open_Virtualization_Format OVF] or similar) and the xl toolstack configuration file and disk image formats.<br />
<br />
[[GSoC_2013#xl-to-xcp-vm-motion]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Advanced Scheduling Parameters<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
The credit scheduler provides a range of "knobs" to control guest behavior, including CPU weight and caps. However,<br />
a number of users have requested the ability to encode more advanced scheduling logic. For instance, "Let this VM max out for 5 minutes out of any given hour; but after that, impose a cap of 20%, so that even if the system is idle he can't an unlimited amount of CPU power without paying for a higher level of service."<br />
<br />
This is too coarse-grained to do inside the hypervisor; a user-space tool would be sufficient. The goal of this project would<br />
be to come up with a good way for admins to support these kinds of complex policies in a simple and robust way.<br />
<br />
|GSoC=Yes<br />
}}<br />
<br />
<br />
<br />
=== PCI Pass-through improvements ===<br />
<br />
{{project<br />
|Project=Allowing guests to boot with a passed-through GPU as the primary display<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
One of the primary drivers of Xen in the "consumer market" of the open-source world is the ability to<br />
pass through GPUs to guests -- allowing people to run Linux as their main desktop but easily play <br />
games requiring proprietary operating systems without rebooting.<br />
<br />
GPUs can be easily passed through to guests as secondary displays, but as of yet cannot be passed<br />
through as primary displays. The main reason is the lack of ability to load the VGA BIOS from the card into the guest.<br />
<br />
The purpose of this project would be to allow HVM guests to load the physical card's VGA bios, so that the guest can<br />
boot with it as the primary display.<br />
<br />
[[GSoC_2013#gpu-passthrough]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Improve PCIe Advanced Error Reporting (AER) handling for passed-through devices<br />
|Date=03/04/2014<br />
|Difficulty=Medium-High<br />
|Skills=Understanding of PC server hardware, PCIe, C<br />
|Contact=Matt Wilson <msw@amazon.com><br />
|Outcomes=Patches for libxl, qemu, and perhaps xen-pciback posted<br />
|Desc=Today the xen-pciback driver handles an AER event for passed-through PCI devices. If the device is assigned to a PV guest, it uses xenstore to request a reset from xen-pcifront. If the device is assigned to a HVM guest, the toolstack is notified and is expected to take corrective action.<br />
<br />
The toolstack support for taking corrective action is only implemented in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/python/xen/xend/server/pciif.py;h=27c1b75cfcf2695740e57bde557d2ee04c4d7322;hb=HEAD#l459 xend], not libxl. For HVM guests ideally, the AER event would be propagated into the guest through the device model (qemu) so that the driver inside the guest can take reset actions.<br />
<br />
|GSoC=Yes<br />
}}<br />
<br />
=== XAPI ===<br />
<br />
{{project<br />
|Project=DRBD Integration<br />
|Date=07/01/2013<br />
|Contact=John Morris <john@zultron.com><br />
|Desc=<br />
DRBD is potentially a great addition to the other high-availability features in XenAPI. An architecture of as few as two Dom0s with DRBD mirrored local storage is an inexpensive minimal HA configuration enabling live migration of VMs between physical hosts and providing failover in case of disk failure, and eliminates the need for external storage. This setup can be used in small shop or hobbyist environments, or could be used as a basic unit in a much larger scalable architecture.<br />
<br />
Existing attempts at integrating DRBD sit below the SM layer and thus do not enable one VBD per DRBD device. They also suffer from a split-brain situation that could be avoided by controlling active/standby status from XenAPI.<br />
<br />
DRBD should be implemented as a new SR type on top of LVM. The tools for managing DRBD devices need to be built into storage management, along with the logic for switching the active and standby nodes.<br />
}}<br />
<br />
== New Project Ideas ==<br />
{{Anchor|New_Project_Ideas}}<br />
'''Please add new project ideas here, following '''<br />
<br />
== Archive ==<br />
=== GSoC Projects that were accepted in 2014 ===<br />
<br />
{{project<br />
|Project=Implement Xen PVUSB support in xl/libxl toolstack<br />
|Date=01/12/2012<br />
|Contact=Mentor: George Dunlap, Student: Bo Cao<br />
|GSoC=Yes<br />
|Desc=<br />
xl/libxl does not currently support Xen PVUSB functionality. Port the feature from xm/xend to xl/libxl. Necessary operations include:<br />
* Task 1: Implement PVUSB in xl/libxl, make it functionally equivalent to xm/xend.<br />
* Send to xen-devel mailinglist for review, comments.<br />
* Fix any upcoming issues.<br />
* Repeat until merged to xen-unstable.<br />
* See above for PVUSB drivers for dom0/domU.<br />
* Xen PVUSB supports both PV domUs and HVM guests with PV drivers.<br />
* More info: http://wiki.xen.org/xenwiki/XenUSBPassthrough<br />
{{Comment|[[User:Lars.kurth|Lars.kurth]] 14:14, 23 January 2013 (UTC):}} Should be suitable, but desc needs. Rate in terms of challenges, size and skill. Also kernel functionality is not yet upstreamed. Maybe Suse kernel.<br />
}}<br />
<br />
{{project<br />
|Project=Lazy restore using memory paging<br />
|Date=01/20/2014<br />
|Contact=Mentor: Andres Lagar-Cavilla, Student: Dushyant Behl<br />
|Difficulty=Medium<br />
|GSoC=Yes<br />
|Desc=VM Save/restore results in a boatload of IO and non-trivial downtime as the entire memory footprint of a VM is read from IO.<br />
<br />
Xen memory paging support in x86 is now mature enough to allow for lazy restore, whereby the footprint of a VM is backfilled while the VM executes. If the VM hits a page not yet present, it is eagerly paged in.<br />
<br />
There has been some concern recently about the lack of docs and/or mature tools that use xen-paging. This is a good way to address the problem.<br />
<br />
|Skills= A good understanding of save/restore, and virtualized memory management (e.g. EPT, shadow page tables, etc). In principle the entire project can be implemented in user-space C code, but it may be the case that new hypercalls are needed for performance reasons.<br />
<br />
|Outcomes=Expected outcome:<br />
* Mainline patches for libxc and libxl<br />
}}<br />
<br />
{{project<br />
|Project=HVM per-event-channel interrupts<br />
|Date=01/30/2013<br />
|Contact=Mentor: Paul Durrant, Student: Yandong Han<br />
|Skills=C, some prior knowledge of Xen useful<br />
|Desc=Windows PV drivers currently have to multiplex all event channel processing onto a single interrupt which is registered with Xen using the HVM_PARAM_CALLBACK_IRQ parameter. This results in a lack of scalability when multiple event channels are heavily used, such as when multiple VIFs in the VM as simultaneously under load.<br />
<br />
Goal: Modify Xen to allow each event channel to be bound to a separate interrupt (the association being controlled by the PV drivers in the guest) to allow separate event channel interrupts to be handled by separate vCPUs. There should be no modifications required to the guest OS interrupt logic to support this (as there is with the current Linux PV-on-HVM code) as this will not be possible with a Windows guest.<br />
|Outcomes=Code is submitted to xen-devel@xen.org for inclusion in xen-unstable<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=Mirage OS cloud API support<br />
|Date=28/11/2013<br />
|Contact=Mentor: Dave Scott; Student: Jyotsna Prakash<br />
|Skills=OCaml<br />
|Difficulty=medium<br />
|Desc=<br />
MirageOS (see http://xenproject.org/developers/teams/mirage-os.html, http://www.openmirage.org/) is a type-safe unikernel written in OCaml which generates highly specialised "appliance" VMs that run directly on Xen without requiring an intervening kernel. A MirageOS application typically runs via several communicating kernel instances on the cloud. Today these instances are difficult to manage; we would like to explore strategies for managing these distributed computations using common public cloud APIs such as those exposed by Amazon EC2 and Rackspace.<br />
<br />
First we need to create pure OCaml API bindings for (e.g.) EC2 and Rackspace (purity is needed to ensure portability). These API bindings can then be used to provide operating-system-level abstractions to the unikernels. For example, a traditional VM might hotplug a vCPU; while a MirageOS application would request a "VM create" using the cloud API and "connect" the new instance to the existing network. We should be able to spin up 1000s of "CPUs" by using such APIs in a cluster environment.<br />
<br />
As well as helping Xen/Mirage, the public cloud API bindings will be very useful to other people in other contexts-- a nice side-effect.<br />
<br />
See https://fedoraproject.org/wiki/User:Gholms/EC2_Primer for a primer on how to use EC2<br />
|Outcomes=1. one or more public cloud API bindings plus examples, in a standalone repo on github; 2. an example mirage app which uses these APIs to spin up a new VM<br />
|GSoC=yes<br />
}}<br />
<br />
{{project<br />
|Project=Parallel xenwatch kthread<br />
|Date=01/08/2012<br />
|Difficulty=Low-Medium<br />
|Contact=Mentor: Boris Ostrovsky, Student: Tülin İZER<br />
|Desc=<br />
<br />
Xenwatch is locked with a coarse lock. For a huge number of guests this represents a scalability issue. The need is to rewrite the xenwatch locking in order to support full scalability.<br />
See https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/xen/xenbus/xenbus_xs.c#n768<br />
for the code.<br />
<br />
|Outcomes=Expected outcome:<br />
* Have upstream patches or a draft of them.<br />
* benchmark report of with and without.<br />
|GSoC=Yes<br />
| Skills=You need to have understanding of:<br />
* locks - spinlocks and mutexes<br />
* build Linux kernel<br />
}}<br />
<br />
== Conventions for Projects and Project Mentors == <br />
=== Rules and Advice for Adding Ideas ===<br />
* Be creative<br />
* Add projects into [[#New_Project_Ideas|New Project Ideas]] or improve projects in [[#Unreviewed Project Ideas|Project Ideas that Need Review or more work]] through review comments.<br />
* Use the {{tl|GSoC Project}} template to encode ideas on this page. Please read the [[Template:GSoC Project|Template Documentation]] before you do so.<br />
* 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<br />
* Check that the project meets the [[#Goals|GSoC Program Goals]]<br />
* If you are willing to mentors those ideas, add your name and email to the idea.<br />
* Aspiring mentors should introduce themselves on the most appropriate Xen Project mailing list<br />
<br />
=== Peer Review Goals ===<br />
We strongly recommend and invite project proposers and project mentors to review each others proposals. When you review, please look out for<br />
* Can a student get going and started with the information in the project description<br />
* Are any unstated assumptions in the proposal, is there undefined terminology, etc. in the proposal <br />
* Can the project completed in 3 months (assume that one month is needed for preparation)<br />
* {{Anchor|Goals}}Does the project meet Google Summer of Code goals, which are<br />
** Create and release open source code for the benefit of all<br />
** Inspire young developers to begin participating in open source development<br />
** Help open source projects identify and bring in new developers and committers <br />
** Provide students the opportunity to do work related to their academic pursuits (think "flip bits, not burgers")<br />
** Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)<br />
<br />
=== Peer Review Conventions ===<br />
The {{tl|GSoC Project}} template used to encode GSoC projects, contains some review functionality. Please read the [[Template:GSoC Project|Template Documentation]] before you add a template, also please use the conventions below to make comments.<br />
<br />
<pre><br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} Comment 1<br />
* {{Comment|~~~~:}} Comment 2<br />
</pre><br />
<br />
=== Choosing Projects ===<br />
We have a bi-weekly mentor meeting overlooked by our program management team, which are a core team of 2-3 mentors and a program administrator. This group will work with mentors to ensure that project proposals are of good quality and whether mentors are engaging with the program management team and students in the weeks before the application period ends. <br />
<br />
[[Category:GSoC]]<br />
[[Category:GSoC 2015]]<br />
[[Category:Developers]]<br />
[[Category:Index]]<br />
[[Category:Project]]<br />
[[Category:Transient]] <!-- as if not maintained it becomes stale --></div>Amirmchttps://wiki.xenproject.org/index.php?title=Archived/GSoC_2015&diff=14200Archived/GSoC 20152015-02-09T15:34:34Z<p>Amirmc: Remove the MirageOS projects as they've been ported to the Pioneer Projects page</p>
<hr />
<div>{{InfoLeft|Please read this [http://lists.xen.org/archives/html/xen-devel/2015-02/msg00902.html message] if you are a mentor to and want to prepare for GSoC 2015}}<br />
<br />
__TOC__<br />
<br />
http://1-ps.googleusercontent.com/xk/lUi00NOiZZtaYcm5-HDw_Ypz0k/s.google-melange.appspot.com/www.google-melange.com/soc/content/2-1-20150205/images/gsoc/logo/banner-gsoc2015.png.pagespeed.ce.1-XG35qq3RLrLftld3Q2.png<br />
<br />
== Xen Project ==<br />
<br />
The Xen Project is a Linux Foundation collaborative project that develops the <br />
* [http://xenproject.org/developers/teams/pvops.html Xen related enablers in Linux (PVOPS)]<br />
* [http://xenproject.org/developers/teams/hypervisor.html Xen Hypervisor] (for x86 and [http://xenproject.org/developers/teams/arm-hypervisor.html ARM])<br />
* [http://xenproject.org/developers/teams/xapi.html The XAPI toolstack]<br />
* [http://xenproject.org/developers/teams/mirage-os.html Mirage OS]<br />
* [http://xenproject.org/developers/teams/windows-pv-drivers.html Windows PV Drivers]<br />
* [http://xenproject.org/developers/teams/embedded-and-automotive.html Embedded & Automotive Drivers] <br />
The project also has excellent relationships with its upstreams (Linux Kernel, the BSDs, QEMU and other projects) and upstreams such as Linux distributions. This is reflected in the project list, which contains many interesting cross-project development projects for students.<br />
<br />
== GSoC and Xen Project ==<br />
This page is used to list project ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code (GSOC) 2015]. <br />
<br />
=== Key GSoC resources ===<br />
The Xen Project is planning to apply as a Mentoring Organization. Stay posted.<br />
<br />
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 GSoC Homepage]<br />
* [http://xenproject.org/help/presentations-and-videos/video/xpds14v-panel.html Video with some of our GSoC 2014 participants discussing their experience]<br />
<br />
=== Finding a project that fits you ===<br />
This page lists Xen Project development projects for GSoC that can be picked up by anyone! If you're interesting in hacking Xen Project code and want to become a part of our friendly developer community this is the place to start! Ready for the challenge?<br />
<br />
'''To work on a project:'''<br />
* Find a project that looks interesting (or a bug if you want to start with something simple)<br />
* Send an email to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] (see '''Developer Mailing Lists''') and let us know if you are interested in starting to work or applying on a specific project.<br />
* Post your ideas, questions, RFCs to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] sooner than later so you can get comments and feedback. <br />
<br />
'''You have your own project idea: no problem!'''<br />
* If you have your own project idea, outline what you are trying to do on the mailing list. If you know the right list, post your project idea on [http://www.xenproject.org/help/mailing-list.html mailing list]. Failing that post on xen-devel and we can redirect you to the right list. Make sure you add '''GSoC 2015''' to the subject line.<br />
<br />
'''It is a good idea to ...'''<br><br />
The Xen Project has also participated in the Gnome Outreach Program for Women (OPW) in the past. One of the things we learned by participating in OPW is that you will be more successful, happier and get more out of participating in student programs such as GSoC, if you do a bit of prep-work before writing an application. Here is some stuff you can do:<br />
* Contact your mentor early and get to know him or her<br />
* If the Xen Project is accepted into GSoC, start hanging out on our IRC channel. You can use the #xen-opw IRC channel on freenode.net for now (if accepted, we will create a GSoC channel)<br />
* You may want to ask the mentor for a couple of small bitesize work-items (such as reviewing someones patch, a bitesize bug, ...) and start communicating on the relevant [http://www.xenproject.org/help/mailing-list.html mailing list]. That helps you become familiar with our development process, the mentor and other community members and will help you chose the right project and help you decide whether the Xen project is for you.<br />
* Note that quite a few Xen maintainers used to be GSoC students once. Feel free to ask community dot manager at xenproject dot org to put you in touch with them if you have questions about their experience.<br />
* Any work you submit before applying for a project should be based on xen-unstable development tree, if the project is Xen Hypervisor and/or tools related. Linux kernel related patches should be based on upstream kernel.org Linux git tree (latest version). XAPI and Mirage OS patches should be based on the right codeline too. Check out the '''navigation by audience''' section on the left to find resources.<br />
<br />
==== More resources ====<br />
Quick links to changelogs of the various Xen related repositories/trees: Please see [[XenRepositories]] wiki page!<br />
<br />
Before to submit patches, please look at [[Submitting Xen Patches]] wiki page and the relevant [http://www.xenproject.org/developers/teams.html Xen Project team page]. This will contain more information.<br />
<br />
If you have new ideas, suggestions or development plans let us know and we'll update this list!<br />
<br />
=== Aspiring Students ===<br />
* Please contact the mentor and CC the most appropriate mailing list<br />
* Get a bite-size task from the mentor before the application starts<br />
* If you feel comfortable with an idea, please put your name to an idea using the following format<br />
<pre><br />
{{project<br />
...<br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} I am interested in this idea ... <br />
(note that you may also want to link to the e-mail thread with the mentor)<br />
</pre><br />
* You will need to request write access to the wiki by filling out [http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html this form]<br />
<br />
=== Applying for GSoC ===<br />
{{InfoLeft|Note that we will update this section when more student information on [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 melange] is available, to make it easier for you to find information. And of course assuming that the Xen Project will be accepted into GSoC.}}<br />
<br />
To apply for a project, follow the steps outlined on<br />
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 melange]<br />
* We do have our own [[GSoC Student Application Template]] form<br />
<br />
== List of peer reviewed Projects ==<br />
=== Domain support (PVOPS and Linux) ===<br />
<br />
{{project<br />
|Project=Utilize Intel QuickData on network and block path.<br />
|Date=01/22/2013<br />
|Difficulty=High<br />
|Contact=Konrad Rzeszutek Wilk <konrad.wilk@oracle.com><br />
|Desc=The Intel QuickData, also known as Direct Cache Access (or IOA/T), is the chipset that sits in the PCIe subsystem in the Intel systems. It allows the PCIe subsystem to tag which PCIe writes to memory should reside in the Last Level Cache (LLC, also known as L3, which in some cases can be of 15MB or 2.5MB per CPU). This offers incredible boosts of speed - as we bypass the DIMMs and instead the CPU can process the data in the cache.<br />
<br />
Adding this component in the network or block backends can mean that we can keep the data longer in the cache and the guest can process the data right off the cache.<br />
<br />
See these for references:<br />
http://www.intel.com/content/www/us/en/wireless-network/accel-technology.html<br />
http://www.intel.com/content/www/us/en/chipsets/quickdata-technology-software-guide-for-linux-paper.html<br />
<br />
Also the dmaengine@vger.kernel.org is an excellent mailing list to subscribe to.<br />
<br />
|Skills=The basic requirement for this project is Linux kernel programming skill.<br />
The candidate for this project should be familiar with open source development workflow as it may require collaboration with several parties.<br />
<br />
|Outcomes=Expected outcome:<br />
* Investigate whether DCA (aka QuickData aka I/O AT) works with Xen.<br />
* If above is true: have upstream patches (or draft patches)<br />
* and benchmark report of with and without.<br />
|GSoC=Yes<br />
}} <br />
<br />
{{project<br />
|Project=Xen block backend/frontend multiqueue support<br />
|Date=03/09/2014<br />
|Difficulty=High<br />
|Contact=Konrad Rzeszutek Wilk <konrad.wilk@oracle.com><br />
|Desc=<br />
The Linux kernel (and FreeBSD, Windows, etc) have ParaVirtualized (PV) drivers to perform<br />
the I/O instead of using the emulated devices that appear in QEMU (IDE, SCSI, etc). This is<br />
done because the emulation of the IDE drivers is quite slow - and if you dig in how it<br />
actually is done - it is full of bit-banging registers. The PV drivers are an answer to this<br />
and eliminate the need for emulation. The mechanism by which they work is <br />
nicely draw out in http://wiki.xen.org/wiki/PV_Protocol<br />
and http://www.informit.com/articles/article.aspx?p=1160234&seqNum=3<br />
("Definitive Guide to the Xen Hypervisor, The")<br />
<br />
There have been improvements done in it - see http://wiki.xen.org/wiki/Xen_4.3_Block_Protocol_Scalability<br />
and http://blog.xen.org/index.php/2013/08/07/indirect-descriptors-for-xen-pv-disks/<br />
<br />
However, there are still room for improvement. We can utilize the new<br />
block multiqueue API support in Linux (See https://lwn.net/Articles/552904/<br />
and http://kernel.dk/systor13-final18.pdf)<br />
to allocate per CPU a block thread (which handles the I/O transmission).<br />
<br />
That should provide greater throughput and lower latency for I/O workloads.<br />
<br />
Also see https://docs.google.com/document/d/1Vh5T8Z3Tx3sUEhVB0DnNDKBNiqB_ZA8Z5YVqAsCIjuI<br />
which has some of the explanation.<br />
<br />
| Skills=You need to have understanding of:<br />
* Knowledge of Linux kernel<br />
* How I/O works<br />
* C language<br />
|Outcomes=Expected outcome:<br />
* Patches for the Linux Kernel Mailing list (LKML).<br />
* Benchmark reports.<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Enabling the 9P File System transport as a paravirt device<br />
|Date=01/20/2014<br />
|Difficulty=High<br />
|Contact=Andres Lagar-Cavilla <andres@lagarcavilla.org><br />
|GSoC=Yes<br />
|Desc=VirtIO provides a 9P FS transport, which is essentially a paravirt file system device. VMs can mount arbitrary file system hierarchies exposed by the backend. The 9P FS specification has been around for a while, while the VirtIO transport is relatively new. The project would consist of implementing a classic Xen front/back pv driver pair to provide a transport for the 9P FS Protocol.<br />
<br />
* More info: http://www.linux-kvm.org/page/9p_virtio<br />
* Also the Bell Labs original OS that introduced the 9P protocol: http://plan9.bell-labs.com/sources/plan9/sys/src/<br />
<br />
|Skills= Required skills include knowledge of kernel hacking, file system internals. Desired skills include: understanding of Xen PV driver structure, and VirtIO.<br />
<br />
|Outcomes=Expected outcome:<br />
* LKML patches for front and back end drivers. <br />
* In particular, domain should be able to boot from the 9P FS.<br />
|Review=(delete as addressed)<br />
* {{Comment|[[User:Lars.kurth|Lars.kurth]] 15:24, 17 February 2014 (UTC):}} This project would benefit from links to the virtio specs and documents explaining how the PV protocol works.<br />
}}<br />
<br />
=== Xen Hypervisor Userspace Tools ===<br />
<br />
{{project<br />
|Project=CPU/RAM/PCI diagram tool<br />
|Date=01/30/2014<br />
|Contact=Andrew Cooper <andrew.cooper3@citrix.com><br />
|Difficulty=Moderate, to Extremely Difficult (depending on which area of the problem you choose to tackle)<br />
|Skills=Understanding of PC server hardware, Understanding of ACPI/SMBios tables, Linux scripting or kernel hacking (depending on which area of the problem you choose to tackle)<br />
|Desc=It is often useful in debugging kernel, hypervisor or performance problems to understand the bus topology of a server. This project will create a layout diagram for a server automatically using data from ACPI Tables, SMBios Tables, lspci output etc. This tool would be useful in general Linux environments including Xen and KVM based virtualisation systems.<br />
<br />
There are many avenues for extension such as labelling relevant hardware errata, performing bus throughput calculations etc.<br />
|Outcomes=A tool is created that can either run on a live Linux system or offline using captured data to produce a graphical representation of the hardware topology of the system including bus topology, hardware device locations, memory bank locations, etc. The tool would be submitted to a suitable open-source project such as the Xen hypervisor project or XCP.<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=KDD (Windows Debugger Stub) enhancements<br />
|Date=01/30/2014<br />
|Contact=Paul Durrant <paul.durrant@citrix.com><br />
|Difficulty=Medium<br />
|Skills=C, Kernel Debuggers, Xen, Windows<br />
|Desc=kdd is a Windows Debugger Stub for Xen hypervisor. It is OSS found under http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/debugger/kdd;h=fd82789a678fb8060cc74ebbe0a04dc58309d6d7;hb=refs/heads/master<br />
kdd allows you to debug a running Windows virtual machine on Xen using standard Windows kernel debugging tools like WinDbg. kdd is an external debugger stub for the windows kernel. <br />
Windows can be debugged without enabling the debugger stub inside windows kernel by using kdd. This is important for debugging hard to reproduce problems on Windows virtual machines that may not have debugging enabled.<br />
<br />
Expected Results:<br />
# Add support for Windows 8 (x86, x64) to kdd<br />
# Add support for Windows Server 2012 to kdd<br />
# Enhance kdd to allow WinDbg to write out usable Windows memory dumps (via .dump debugger extension) for all supported versions<br />
# Produce a user guide for kdd on Xen wiki page<br />
<br />
Nice to have: Allow kdd to operate on a Windows domain checkpoint file (output of xl save for e.g.)<br />
|Outcomes=Code is submitted to xen-devel@xen.org for inclusion in the xen-unstable project.<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=CPUID Programming for Humans<br />
|Date=02/04/2014<br />
|Contact=Andres Lagar-Cavilla <andres@lagarcavilla.org><br />
|Difficulty=Easy<br />
|GSoC=Yes<br />
|Desc=When creating a VM, a policy is applied to mask certain CPUID features. Right now it's black magic.<br />
<br />
The KVM stack has done an excellent job of making this human-useable, and understandable.<br />
<br />
For example, in a qemu-kvm command-line you may encounter:<br />
<pre><br />
-cpu SandyBridge,+pdpe1gb,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,<br />
+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme<br />
</pre><br />
<br />
And in <qemu>/target-i386.c you find a fairly comprehensive description of x86 processor models, what CPUID features are inherent, and what CPUID feature each of these symbolic flags enables.<br />
<br />
In the Xen world, there is a libxc interface to do the same, although it's all hex and register driven. It's effective, yet horrible to use.<br />
<br />
An ideal outcome would have libxl config files and command line absorb a similarly human-friendly description of the CPUID features a user wishes for the VM, and interface appropriately with libxl. Further, autodetection of best CPUID shuold yield a human-readable output to be able to easily understand what the VM thinks about its processor.<br />
<br />
Finally, interfacing with libvirt should be carefully considered.<br />
<br />
CPUID management is crucial in a heterogeneous cluster where migrations and save restore require careful processor feature selection to avoid blow-ups.<br />
<br />
See: <br />
* http://wiki.qemu.org/images/c/c8/Cpu-models-and-libvirt-devconf-2014.pdf<br />
* https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/<br />
* http://blog.xen.org/index.php/2014/01/17/libvirt-support-for-xens-new-libxenlight-toolstack/<br />
|Skills= A good understanding of C user-land programming, and the ability to dive into qemu/libvirt (for reference code and integration), as well as libxc and libxl (for implementation).<br />
<br />
|Outcomes=Expected outcome:<br />
* Mainline patches for libxl<br />
}}<br />
<br />
{{project<br />
|Project=Rump kernel based stubdom<br />
|Date=Feb 06 2014<br />
|Verified=Feb 06 2014<br />
|Contact=Wei Liu <wei.liu2@citrix.com><br />
|Difficulty=Easy<br />
|GSoC=Yes<br />
|Desc=Stubdom can help boost performance and security. Currently stubdom is not very nice to work with. It employs an ancient version of newlib and the build system is fragile.<br />
<br />
Rump kernel (a way to implement unikernel / library OS) already runs on Xen and it uses NetBSD's libraries which are much more maintainable. This project aims to port existing stubdoms (c, xenstore, ocaml etc) to rump kernel.<br />
<br />
During this process, student can get first hand experience on Xen and rump kernel and tackle both kernel level and application level problems. The experience on the frontier of OS development and research is also valuable. Student should be able to understand how a to turn a piece of software into unikernel when he / she finishes this project.<br />
<br />
Useful links:<br />
<br />
* http://rumpkernel.org/<br />
<br />
|Skills= Knowledge of operating system, GNU autotools, C programming and good debugging skills.<br />
<br />
|Outcomes=Patches for Xen and rump kernel.<br />
}}<br />
<br />
=== MirageOS ===<br />
<br />
{{project<br />
|Project=Various MirageOS Pioneer Projects<br />
|Date=01/30/2015<br />
|Verified=Feb 8th, 2015 (see this [http://lists.xenproject.org/archives/html/mirageos-devel/2015-02/msg00046.html conversation])<br />
|Contact=Send a mail to mirageos-devel@lists.xenproject.org if you're interested in starting on one or several of these projects. <br />
|Difficulty=Various levels of difficulty<br />
|Skills=OCaml<br />
|Desc=This is a list of pioneer projects for Mirage OS, covering area such as '''Build Tools''', '''New Libraries''', '''Storage Technologies''', '''Networking Technologies''', '''Interfaces to Non-Ocaml (aka foreign) Languages''' and other topics. Note that some of these projects may be too small or too big for a single GSoC project. If you are interested in one of these, make sure you discuss first on mirageos-devel@lists.xenproject.org - we can then merge or split these as needed for GSoC.<br />
<br />
References:<br />
* [https://github.com/mirage/mirage-www/wiki/Pioneer-Projects Complete list of Pioneer Projects]<br />
<br />
|GSoC=yes, but do check mirageos-devel@lists.xenproject.org first<br />
}}<br />
<br />
== List of projects that need more work ==<br />
{{Anchor|Unreviewed Project Ideas}}<br />
<br />
=== Xen Hypervisor ===<br />
<br />
{{project<br />
|Project=Introducing PowerClamp-like driver for Xen<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
PowerClamp was introduced to Linux in late 2012 in order to allow users to set a system-wide maximum<br />
power usage limit. This is particularly useful for data centers, where there may be a need to<br />
reduce power consumption based on availability of electricity or cooling. A [http://lwn.net/Articles/528124/ more complete writeup]<br />
is available at LWN.<br />
<br />
These same arguments apply to Xen. The purpose of this project would be to implement a similar functionality in Xen,<br />
and to make it interface as well as possible with the Linux PowerClamp tools, so that the same tools could be used<br />
for both. [[GSoC_2013#powerclamp-for-xen]]<br />
|GSoC=Yes<br />
}}<br />
<br />
=== Xen Hypervisor Userspace Tools ===<br />
{{project<br />
|Project=Refactor Linux hotplug scripts<br />
|Date=15/11/2012<br />
|Contact=Roger Pau Monné <[mailto:roger.pau@citrix.com roger.pau@citrix.com]><br />
|Desc=<br />
Current Linux hotplug scripts are all entangled, which makes them really difficult to understand or modify. The reason of hotplug scripts is to give end-users the chance to "easily" support different configuration for Xen devices.<br />
<br />
Linux hotplug scripts should be analized, providing a good description of what each hotplug script is doing. After this, scripts should be cleaned, putting common pieces of code in shared files across all scripts. A Coding style should be applied to all of them when the refactoring is finished.<br />
<br />
[[GSoC_2013#linux-hotplug-scripts]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=XL to XCP VM motion<br />
|Date=15/11/12<br />
|Contact=[mailto:ian.campbell@citrix.com Ian Campbell]<br />
|Desc=Currently [[XL|xl]] (the toolstack supplied alongside Xen) and [[XAPI|xapi]] (the XCP toolstack) have very different concepts about domain configuration, disk image storage etc. In the XCP model domain configuration is persistent and stored in a data base while under xl domain configuration is written in configuration files. Likewise disk images are stored as VDIs in Storage Repositories while under xl disk images are simply files or devices in the dom0 filesystem. For more information on xl see [[XL]]. For more information on XCP see [[XCP Overview]].<br />
<br />
This project is to produce one or more command-line tools which support migrating VMs between these toolstacks.<br />
<br />
One tool should be provided which takes an xl configuration file and details of an XCP pool. Using the XenAPI XML/RPC interface It should create a VM in the pool with a close approximation of the same configuration and stream the configured disk image into a selected Storage Repository.<br />
<br />
A second tool should be provided which performs the opposite operation, i.e. give a reference to a VM residing in an XCP pool it should produce an XL compatible configuration file and stream the disk image(s) our of Xapi into a suitable format.<br />
<br />
These tools could be reasonably bundled as part of either toolstack and by implication could be written in either C, Ocaml or some other suitable language.<br />
<br />
The tool need not operate on a live VM but that could be considered a stretch goal.<br />
<br />
An acceptable alternative to the proposed implementation would be to implement a tool which converts between a commonly used VM container format which is supported by XCP (perhaps [http://en.wikipedia.org/wiki/Open_Virtualization_Format OVF] or similar) and the xl toolstack configuration file and disk image formats.<br />
<br />
[[GSoC_2013#xl-to-xcp-vm-motion]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Advanced Scheduling Parameters<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
The credit scheduler provides a range of "knobs" to control guest behavior, including CPU weight and caps. However,<br />
a number of users have requested the ability to encode more advanced scheduling logic. For instance, "Let this VM max out for 5 minutes out of any given hour; but after that, impose a cap of 20%, so that even if the system is idle he can't an unlimited amount of CPU power without paying for a higher level of service."<br />
<br />
This is too coarse-grained to do inside the hypervisor; a user-space tool would be sufficient. The goal of this project would<br />
be to come up with a good way for admins to support these kinds of complex policies in a simple and robust way.<br />
<br />
|GSoC=Yes<br />
}}<br />
<br />
<br />
<br />
=== PCI Pass-through improvements ===<br />
<br />
{{project<br />
|Project=Allowing guests to boot with a passed-through GPU as the primary display<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
One of the primary drivers of Xen in the "consumer market" of the open-source world is the ability to<br />
pass through GPUs to guests -- allowing people to run Linux as their main desktop but easily play <br />
games requiring proprietary operating systems without rebooting.<br />
<br />
GPUs can be easily passed through to guests as secondary displays, but as of yet cannot be passed<br />
through as primary displays. The main reason is the lack of ability to load the VGA BIOS from the card into the guest.<br />
<br />
The purpose of this project would be to allow HVM guests to load the physical card's VGA bios, so that the guest can<br />
boot with it as the primary display.<br />
<br />
[[GSoC_2013#gpu-passthrough]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Improve PCIe Advanced Error Reporting (AER) handling for passed-through devices<br />
|Date=03/04/2014<br />
|Difficulty=Medium-High<br />
|Skills=Understanding of PC server hardware, PCIe, C<br />
|Contact=Matt Wilson <msw@amazon.com><br />
|Outcomes=Patches for libxl, qemu, and perhaps xen-pciback posted<br />
|Desc=Today the xen-pciback driver handles an AER event for passed-through PCI devices. If the device is assigned to a PV guest, it uses xenstore to request a reset from xen-pcifront. If the device is assigned to a HVM guest, the toolstack is notified and is expected to take corrective action.<br />
<br />
The toolstack support for taking corrective action is only implemented in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/python/xen/xend/server/pciif.py;h=27c1b75cfcf2695740e57bde557d2ee04c4d7322;hb=HEAD#l459 xend], not libxl. For HVM guests ideally, the AER event would be propagated into the guest through the device model (qemu) so that the driver inside the guest can take reset actions.<br />
<br />
|GSoC=Yes<br />
}}<br />
<br />
=== XAPI ===<br />
<br />
{{project<br />
|Project=DRBD Integration<br />
|Date=07/01/2013<br />
|Contact=John Morris <john@zultron.com><br />
|Desc=<br />
DRBD is potentially a great addition to the other high-availability features in XenAPI. An architecture of as few as two Dom0s with DRBD mirrored local storage is an inexpensive minimal HA configuration enabling live migration of VMs between physical hosts and providing failover in case of disk failure, and eliminates the need for external storage. This setup can be used in small shop or hobbyist environments, or could be used as a basic unit in a much larger scalable architecture.<br />
<br />
Existing attempts at integrating DRBD sit below the SM layer and thus do not enable one VBD per DRBD device. They also suffer from a split-brain situation that could be avoided by controlling active/standby status from XenAPI.<br />
<br />
DRBD should be implemented as a new SR type on top of LVM. The tools for managing DRBD devices need to be built into storage management, along with the logic for switching the active and standby nodes.<br />
}}<br />
<br />
== New Project Ideas ==<br />
{{Anchor|New_Project_Ideas}}<br />
'''Please add new project ideas here, following '''<br />
<br />
== Archive ==<br />
=== GSoC Projects that were accepted in 2014 ===<br />
<br />
{{project<br />
|Project=Implement Xen PVUSB support in xl/libxl toolstack<br />
|Date=01/12/2012<br />
|Contact=Mentor: George Dunlap, Student: Bo Cao<br />
|GSoC=Yes<br />
|Desc=<br />
xl/libxl does not currently support Xen PVUSB functionality. Port the feature from xm/xend to xl/libxl. Necessary operations include:<br />
* Task 1: Implement PVUSB in xl/libxl, make it functionally equivalent to xm/xend.<br />
* Send to xen-devel mailinglist for review, comments.<br />
* Fix any upcoming issues.<br />
* Repeat until merged to xen-unstable.<br />
* See above for PVUSB drivers for dom0/domU.<br />
* Xen PVUSB supports both PV domUs and HVM guests with PV drivers.<br />
* More info: http://wiki.xen.org/xenwiki/XenUSBPassthrough<br />
{{Comment|[[User:Lars.kurth|Lars.kurth]] 14:14, 23 January 2013 (UTC):}} Should be suitable, but desc needs. Rate in terms of challenges, size and skill. Also kernel functionality is not yet upstreamed. Maybe Suse kernel.<br />
}}<br />
<br />
{{project<br />
|Project=Lazy restore using memory paging<br />
|Date=01/20/2014<br />
|Contact=Mentor: Andres Lagar-Cavilla, Student: Dushyant Behl<br />
|Difficulty=Medium<br />
|GSoC=Yes<br />
|Desc=VM Save/restore results in a boatload of IO and non-trivial downtime as the entire memory footprint of a VM is read from IO.<br />
<br />
Xen memory paging support in x86 is now mature enough to allow for lazy restore, whereby the footprint of a VM is backfilled while the VM executes. If the VM hits a page not yet present, it is eagerly paged in.<br />
<br />
There has been some concern recently about the lack of docs and/or mature tools that use xen-paging. This is a good way to address the problem.<br />
<br />
|Skills= A good understanding of save/restore, and virtualized memory management (e.g. EPT, shadow page tables, etc). In principle the entire project can be implemented in user-space C code, but it may be the case that new hypercalls are needed for performance reasons.<br />
<br />
|Outcomes=Expected outcome:<br />
* Mainline patches for libxc and libxl<br />
}}<br />
<br />
{{project<br />
|Project=HVM per-event-channel interrupts<br />
|Date=01/30/2013<br />
|Contact=Mentor: Paul Durrant, Student: Yandong Han<br />
|Skills=C, some prior knowledge of Xen useful<br />
|Desc=Windows PV drivers currently have to multiplex all event channel processing onto a single interrupt which is registered with Xen using the HVM_PARAM_CALLBACK_IRQ parameter. This results in a lack of scalability when multiple event channels are heavily used, such as when multiple VIFs in the VM as simultaneously under load.<br />
<br />
Goal: Modify Xen to allow each event channel to be bound to a separate interrupt (the association being controlled by the PV drivers in the guest) to allow separate event channel interrupts to be handled by separate vCPUs. There should be no modifications required to the guest OS interrupt logic to support this (as there is with the current Linux PV-on-HVM code) as this will not be possible with a Windows guest.<br />
|Outcomes=Code is submitted to xen-devel@xen.org for inclusion in xen-unstable<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=Mirage OS cloud API support<br />
|Date=28/11/2013<br />
|Contact=Mentor: Dave Scott; Student: Jyotsna Prakash<br />
|Skills=OCaml<br />
|Difficulty=medium<br />
|Desc=<br />
MirageOS (see http://xenproject.org/developers/teams/mirage-os.html, http://www.openmirage.org/) is a type-safe unikernel written in OCaml which generates highly specialised "appliance" VMs that run directly on Xen without requiring an intervening kernel. A MirageOS application typically runs via several communicating kernel instances on the cloud. Today these instances are difficult to manage; we would like to explore strategies for managing these distributed computations using common public cloud APIs such as those exposed by Amazon EC2 and Rackspace.<br />
<br />
First we need to create pure OCaml API bindings for (e.g.) EC2 and Rackspace (purity is needed to ensure portability). These API bindings can then be used to provide operating-system-level abstractions to the unikernels. For example, a traditional VM might hotplug a vCPU; while a MirageOS application would request a "VM create" using the cloud API and "connect" the new instance to the existing network. We should be able to spin up 1000s of "CPUs" by using such APIs in a cluster environment.<br />
<br />
As well as helping Xen/Mirage, the public cloud API bindings will be very useful to other people in other contexts-- a nice side-effect.<br />
<br />
See https://fedoraproject.org/wiki/User:Gholms/EC2_Primer for a primer on how to use EC2<br />
|Outcomes=1. one or more public cloud API bindings plus examples, in a standalone repo on github; 2. an example mirage app which uses these APIs to spin up a new VM<br />
|GSoC=yes<br />
}}<br />
<br />
{{project<br />
|Project=Parallel xenwatch kthread<br />
|Date=01/08/2012<br />
|Difficulty=Low-Medium<br />
|Contact=Mentor: Boris Ostrovsky, Student: Tülin İZER<br />
|Desc=<br />
<br />
Xenwatch is locked with a coarse lock. For a huge number of guests this represents a scalability issue. The need is to rewrite the xenwatch locking in order to support full scalability.<br />
See https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/xen/xenbus/xenbus_xs.c#n768<br />
for the code.<br />
<br />
|Outcomes=Expected outcome:<br />
* Have upstream patches or a draft of them.<br />
* benchmark report of with and without.<br />
|GSoC=Yes<br />
| Skills=You need to have understanding of:<br />
* locks - spinlocks and mutexes<br />
* build Linux kernel<br />
}}<br />
<br />
== Conventions for Projects and Project Mentors == <br />
=== Rules and Advice for Adding Ideas ===<br />
* Be creative<br />
* Add projects into [[#New_Project_Ideas|New Project Ideas]] or improve projects in [[#Unreviewed Project Ideas|Project Ideas that Need Review or more work]] through review comments.<br />
* Use the {{tl|GSoC Project}} template to encode ideas on this page. Please read the [[Template:GSoC Project|Template Documentation]] before you do so.<br />
* 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<br />
* Check that the project meets the [[#Goals|GSoC Program Goals]]<br />
* If you are willing to mentors those ideas, add your name and email to the idea.<br />
* Aspiring mentors should introduce themselves on the most appropriate Xen Project mailing list<br />
<br />
=== Peer Review Goals ===<br />
We strongly recommend and invite project proposers and project mentors to review each others proposals. When you review, please look out for<br />
* Can a student get going and started with the information in the project description<br />
* Are any unstated assumptions in the proposal, is there undefined terminology, etc. in the proposal <br />
* Can the project completed in 3 months (assume that one month is needed for preparation)<br />
* {{Anchor|Goals}}Does the project meet Google Summer of Code goals, which are<br />
** Create and release open source code for the benefit of all<br />
** Inspire young developers to begin participating in open source development<br />
** Help open source projects identify and bring in new developers and committers <br />
** Provide students the opportunity to do work related to their academic pursuits (think "flip bits, not burgers")<br />
** Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)<br />
<br />
=== Peer Review Conventions ===<br />
The {{tl|GSoC Project}} template used to encode GSoC projects, contains some review functionality. Please read the [[Template:GSoC Project|Template Documentation]] before you add a template, also please use the conventions below to make comments.<br />
<br />
<pre><br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} Comment 1<br />
* {{Comment|~~~~:}} Comment 2<br />
</pre><br />
<br />
=== Choosing Projects ===<br />
We have a bi-weekly mentor meeting overlooked by our program management team, which are a core team of 2-3 mentors and a program administrator. This group will work with mentors to ensure that project proposals are of good quality and whether mentors are engaging with the program management team and students in the weeks before the application period ends. <br />
<br />
[[Category:GSoC]]<br />
[[Category:GSoC 2015]]<br />
[[Category:Developers]]<br />
[[Category:Index]]<br />
[[Category:Project]]<br />
[[Category:Transient]] <!-- as if not maintained it becomes stale --></div>Amirmchttps://wiki.xenproject.org/index.php?title=Archived/GSoC_2015&diff=14174Archived/GSoC 20152015-02-09T13:00:00Z<p>Amirmc: Add back link to MirageOS pioneer projects page - AC</p>
<hr />
<div>{{InfoLeft|Please read this [http://lists.xen.org/archives/html/xen-devel/2015-02/msg00902.html message] if you are a mentor to and want to prepare for GSoC 2015}}<br />
<br />
__TOC__<br />
<br />
http://1-ps.googleusercontent.com/xk/lUi00NOiZZtaYcm5-HDw_Ypz0k/s.google-melange.appspot.com/www.google-melange.com/soc/content/2-1-20150205/images/gsoc/logo/banner-gsoc2015.png.pagespeed.ce.1-XG35qq3RLrLftld3Q2.png<br />
<br />
== Xen Project ==<br />
<br />
The Xen Project is a Linux Foundation collaborative project that develops the <br />
* [http://xenproject.org/developers/teams/pvops.html Xen related enablers in Linux (PVOPS)]<br />
* [http://xenproject.org/developers/teams/hypervisor.html Xen Hypervisor] (for x86 and [http://xenproject.org/developers/teams/arm-hypervisor.html ARM])<br />
* [http://xenproject.org/developers/teams/xapi.html The XAPI toolstack]<br />
* [http://xenproject.org/developers/teams/mirage-os.html Mirage OS]<br />
* [http://xenproject.org/developers/teams/windows-pv-drivers.html Windows PV Drivers]<br />
* [http://xenproject.org/developers/teams/embedded-and-automotive.html Embedded & Automotive Drivers] <br />
The project also has excellent relationships with its upstreams (Linux Kernel, the BSDs, QEMU and other projects) and upstreams such as Linux distributions. This is reflected in the project list, which contains many interesting cross-project development projects for students.<br />
<br />
== GSoC and Xen Project ==<br />
This page is used to list project ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code (GSOC) 2015]. <br />
<br />
=== Key GSoC resources ===<br />
The Xen Project is planning to apply as a Mentoring Organization. Stay posted.<br />
<br />
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 GSoC Homepage]<br />
* [http://xenproject.org/help/presentations-and-videos/video/xpds14v-panel.html Video with some of our GSoC 2014 participants discussing their experience]<br />
<br />
=== Finding a project that fits you ===<br />
This page lists Xen Project development projects for GSoC that can be picked up by anyone! If you're interesting in hacking Xen Project code and want to become a part of our friendly developer community this is the place to start! Ready for the challenge?<br />
<br />
'''To work on a project:'''<br />
* Find a project that looks interesting (or a bug if you want to start with something simple)<br />
* Send an email to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] (see '''Developer Mailing Lists''') and let us know if you are interested in starting to work or applying on a specific project.<br />
* Post your ideas, questions, RFCs to the relevant [http://www.xenproject.org/help/mailing-list.html mailing list] sooner than later so you can get comments and feedback. <br />
<br />
'''You have your own project idea: no problem!'''<br />
* If you have your own project idea, outline what you are trying to do on the mailing list. If you know the right list, post your project idea on [http://www.xenproject.org/help/mailing-list.html mailing list]. Failing that post on xen-devel and we can redirect you to the right list. Make sure you add '''GSoC 2015''' to the subject line.<br />
<br />
'''It is a good idea to ...'''<br><br />
The Xen Project has also participated in the Gnome Outreach Program for Women (OPW) in the past. One of the things we learned by participating in OPW is that you will be more successful, happier and get more out of participating in student programs such as GSoC, if you do a bit of prep-work before writing an application. Here is some stuff you can do:<br />
* Contact your mentor early and get to know him or her<br />
* If the Xen Project is accepted into GSoC, start hanging out on our IRC channel. You can use the #xen-opw IRC channel on freenode.net for now (if accepted, we will create a GSoC channel)<br />
* You may want to ask the mentor for a couple of small bitesize work-items (such as reviewing someones patch, a bitesize bug, ...) and start communicating on the relevant [http://www.xenproject.org/help/mailing-list.html mailing list]. That helps you become familiar with our development process, the mentor and other community members and will help you chose the right project and help you decide whether the Xen project is for you.<br />
* Note that quite a few Xen maintainers used to be GSoC students once. Feel free to ask community dot manager at xenproject dot org to put you in touch with them if you have questions about their experience.<br />
* Any work you submit before applying for a project should be based on xen-unstable development tree, if the project is Xen Hypervisor and/or tools related. Linux kernel related patches should be based on upstream kernel.org Linux git tree (latest version). XAPI and Mirage OS patches should be based on the right codeline too. Check out the '''navigation by audience''' section on the left to find resources.<br />
<br />
==== More resources ====<br />
Quick links to changelogs of the various Xen related repositories/trees: Please see [[XenRepositories]] wiki page!<br />
<br />
Before to submit patches, please look at [[Submitting Xen Patches]] wiki page and the relevant [http://www.xenproject.org/developers/teams.html Xen Project team page]. This will contain more information.<br />
<br />
If you have new ideas, suggestions or development plans let us know and we'll update this list!<br />
<br />
=== Aspiring Students ===<br />
* Please contact the mentor and CC the most appropriate mailing list<br />
* Get a bite-size task from the mentor before the application starts<br />
* If you feel comfortable with an idea, please put your name to an idea using the following format<br />
<pre><br />
{{project<br />
...<br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} I am interested in this idea ... <br />
(note that you may also want to link to the e-mail thread with the mentor)<br />
</pre><br />
* You will need to request write access to the wiki by filling out [http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html this form]<br />
<br />
=== Applying for GSoC ===<br />
{{InfoLeft|Note that we will update this section when more student information on [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 melange] is available, to make it easier for you to find information. And of course assuming that the Xen Project will be accepted into GSoC.}}<br />
<br />
To apply for a project, follow the steps outlined on<br />
* [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 melange]<br />
* We do have our own [[GSoC Student Application Template]] form<br />
<br />
== List of peer reviewed Projects ==<br />
=== Domain support (PVOPS and Linux) ===<br />
<br />
{{project<br />
|Project=Utilize Intel QuickData on network and block path.<br />
|Date=01/22/2013<br />
|Difficulty=High<br />
|Contact=Konrad Rzeszutek Wilk <konrad.wilk@oracle.com><br />
|Desc=The Intel QuickData, also known as Direct Cache Access (or IOA/T), is the chipset that sits in the PCIe subsystem in the Intel systems. It allows the PCIe subsystem to tag which PCIe writes to memory should reside in the Last Level Cache (LLC, also known as L3, which in some cases can be of 15MB or 2.5MB per CPU). This offers incredible boosts of speed - as we bypass the DIMMs and instead the CPU can process the data in the cache.<br />
<br />
Adding this component in the network or block backends can mean that we can keep the data longer in the cache and the guest can process the data right off the cache.<br />
<br />
See these for references:<br />
http://www.intel.com/content/www/us/en/wireless-network/accel-technology.html<br />
http://www.intel.com/content/www/us/en/chipsets/quickdata-technology-software-guide-for-linux-paper.html<br />
<br />
Also the dmaengine@vger.kernel.org is an excellent mailing list to subscribe to.<br />
<br />
|Skills=The basic requirement for this project is Linux kernel programming skill.<br />
The candidate for this project should be familiar with open source development workflow as it may require collaboration with several parties.<br />
<br />
|Outcomes=Expected outcome:<br />
* Investigate whether DCA (aka QuickData aka I/O AT) works with Xen.<br />
* If above is true: have upstream patches (or draft patches)<br />
* and benchmark report of with and without.<br />
|GSoC=Yes<br />
}} <br />
<br />
{{project<br />
|Project=Xen block backend/frontend multiqueue support<br />
|Date=03/09/2014<br />
|Difficulty=High<br />
|Contact=Konrad Rzeszutek Wilk <konrad.wilk@oracle.com><br />
|Desc=<br />
The Linux kernel (and FreeBSD, Windows, etc) have ParaVirtualized (PV) drivers to perform<br />
the I/O instead of using the emulated devices that appear in QEMU (IDE, SCSI, etc). This is<br />
done because the emulation of the IDE drivers is quite slow - and if you dig in how it<br />
actually is done - it is full of bit-banging registers. The PV drivers are an answer to this<br />
and eliminate the need for emulation. The mechanism by which they work is <br />
nicely draw out in http://wiki.xen.org/wiki/PV_Protocol<br />
and http://www.informit.com/articles/article.aspx?p=1160234&seqNum=3<br />
("Definitive Guide to the Xen Hypervisor, The")<br />
<br />
There have been improvements done in it - see http://wiki.xen.org/wiki/Xen_4.3_Block_Protocol_Scalability<br />
and http://blog.xen.org/index.php/2013/08/07/indirect-descriptors-for-xen-pv-disks/<br />
<br />
However, there are still room for improvement. We can utilize the new<br />
block multiqueue API support in Linux (See https://lwn.net/Articles/552904/<br />
and http://kernel.dk/systor13-final18.pdf)<br />
to allocate per CPU a block thread (which handles the I/O transmission).<br />
<br />
That should provide greater throughput and lower latency for I/O workloads.<br />
<br />
Also see https://docs.google.com/document/d/1Vh5T8Z3Tx3sUEhVB0DnNDKBNiqB_ZA8Z5YVqAsCIjuI<br />
which has some of the explanation.<br />
<br />
| Skills=You need to have understanding of:<br />
* Knowledge of Linux kernel<br />
* How I/O works<br />
* C language<br />
|Outcomes=Expected outcome:<br />
* Patches for the Linux Kernel Mailing list (LKML).<br />
* Benchmark reports.<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Enabling the 9P File System transport as a paravirt device<br />
|Date=01/20/2014<br />
|Difficulty=High<br />
|Contact=Andres Lagar-Cavilla <andres@lagarcavilla.org><br />
|GSoC=Yes<br />
|Desc=VirtIO provides a 9P FS transport, which is essentially a paravirt file system device. VMs can mount arbitrary file system hierarchies exposed by the backend. The 9P FS specification has been around for a while, while the VirtIO transport is relatively new. The project would consist of implementing a classic Xen front/back pv driver pair to provide a transport for the 9P FS Protocol.<br />
<br />
* More info: http://www.linux-kvm.org/page/9p_virtio<br />
* Also the Bell Labs original OS that introduced the 9P protocol: http://plan9.bell-labs.com/sources/plan9/sys/src/<br />
<br />
|Skills= Required skills include knowledge of kernel hacking, file system internals. Desired skills include: understanding of Xen PV driver structure, and VirtIO.<br />
<br />
|Outcomes=Expected outcome:<br />
* LKML patches for front and back end drivers. <br />
* In particular, domain should be able to boot from the 9P FS.<br />
|Review=(delete as addressed)<br />
* {{Comment|[[User:Lars.kurth|Lars.kurth]] 15:24, 17 February 2014 (UTC):}} This project would benefit from links to the virtio specs and documents explaining how the PV protocol works.<br />
}}<br />
<br />
=== Xen Hypervisor Userspace Tools ===<br />
<br />
{{project<br />
|Project=CPU/RAM/PCI diagram tool<br />
|Date=01/30/2014<br />
|Contact=Andrew Cooper <andrew.cooper3@citrix.com><br />
|Difficulty=Moderate, to Extremely Difficult (depending on which area of the problem you choose to tackle)<br />
|Skills=Understanding of PC server hardware, Understanding of ACPI/SMBios tables, Linux scripting or kernel hacking (depending on which area of the problem you choose to tackle)<br />
|Desc=It is often useful in debugging kernel, hypervisor or performance problems to understand the bus topology of a server. This project will create a layout diagram for a server automatically using data from ACPI Tables, SMBios Tables, lspci output etc. This tool would be useful in general Linux environments including Xen and KVM based virtualisation systems.<br />
<br />
There are many avenues for extension such as labelling relevant hardware errata, performing bus throughput calculations etc.<br />
|Outcomes=A tool is created that can either run on a live Linux system or offline using captured data to produce a graphical representation of the hardware topology of the system including bus topology, hardware device locations, memory bank locations, etc. The tool would be submitted to a suitable open-source project such as the Xen hypervisor project or XCP.<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=KDD (Windows Debugger Stub) enhancements<br />
|Date=01/30/2014<br />
|Contact=Paul Durrant <paul.durrant@citrix.com><br />
|Difficulty=Medium<br />
|Skills=C, Kernel Debuggers, Xen, Windows<br />
|Desc=kdd is a Windows Debugger Stub for Xen hypervisor. It is OSS found under http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/debugger/kdd;h=fd82789a678fb8060cc74ebbe0a04dc58309d6d7;hb=refs/heads/master<br />
kdd allows you to debug a running Windows virtual machine on Xen using standard Windows kernel debugging tools like WinDbg. kdd is an external debugger stub for the windows kernel. <br />
Windows can be debugged without enabling the debugger stub inside windows kernel by using kdd. This is important for debugging hard to reproduce problems on Windows virtual machines that may not have debugging enabled.<br />
<br />
Expected Results:<br />
# Add support for Windows 8 (x86, x64) to kdd<br />
# Add support for Windows Server 2012 to kdd<br />
# Enhance kdd to allow WinDbg to write out usable Windows memory dumps (via .dump debugger extension) for all supported versions<br />
# Produce a user guide for kdd on Xen wiki page<br />
<br />
Nice to have: Allow kdd to operate on a Windows domain checkpoint file (output of xl save for e.g.)<br />
|Outcomes=Code is submitted to xen-devel@xen.org for inclusion in the xen-unstable project.<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=CPUID Programming for Humans<br />
|Date=02/04/2014<br />
|Contact=Andres Lagar-Cavilla <andres@lagarcavilla.org><br />
|Difficulty=Easy<br />
|GSoC=Yes<br />
|Desc=When creating a VM, a policy is applied to mask certain CPUID features. Right now it's black magic.<br />
<br />
The KVM stack has done an excellent job of making this human-useable, and understandable.<br />
<br />
For example, in a qemu-kvm command-line you may encounter:<br />
<pre><br />
-cpu SandyBridge,+pdpe1gb,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,<br />
+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme<br />
</pre><br />
<br />
And in <qemu>/target-i386.c you find a fairly comprehensive description of x86 processor models, what CPUID features are inherent, and what CPUID feature each of these symbolic flags enables.<br />
<br />
In the Xen world, there is a libxc interface to do the same, although it's all hex and register driven. It's effective, yet horrible to use.<br />
<br />
An ideal outcome would have libxl config files and command line absorb a similarly human-friendly description of the CPUID features a user wishes for the VM, and interface appropriately with libxl. Further, autodetection of best CPUID shuold yield a human-readable output to be able to easily understand what the VM thinks about its processor.<br />
<br />
Finally, interfacing with libvirt should be carefully considered.<br />
<br />
CPUID management is crucial in a heterogeneous cluster where migrations and save restore require careful processor feature selection to avoid blow-ups.<br />
<br />
See: <br />
* http://wiki.qemu.org/images/c/c8/Cpu-models-and-libvirt-devconf-2014.pdf<br />
* https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/<br />
* http://blog.xen.org/index.php/2014/01/17/libvirt-support-for-xens-new-libxenlight-toolstack/<br />
|Skills= A good understanding of C user-land programming, and the ability to dive into qemu/libvirt (for reference code and integration), as well as libxc and libxl (for implementation).<br />
<br />
|Outcomes=Expected outcome:<br />
* Mainline patches for libxl<br />
}}<br />
<br />
{{project<br />
|Project=Rump kernel based stubdom<br />
|Date=Feb 06 2014<br />
|Verified=Feb 06 2014<br />
|Contact=Wei Liu <wei.liu2@citrix.com><br />
|Difficulty=Easy<br />
|GSoC=Yes<br />
|Desc=Stubdom can help boost performance and security. Currently stubdom is not very nice to work with. It employs an ancient version of newlib and the build system is fragile.<br />
<br />
Rump kernel (a way to implement unikernel / library OS) already runs on Xen and it uses NetBSD's libraries which are much more maintainable. This project aims to port existing stubdoms (c, xenstore, ocaml etc) to rump kernel.<br />
<br />
During this process, student can get first hand experience on Xen and rump kernel and tackle both kernel level and application level problems. The experience on the frontier of OS development and research is also valuable. Student should be able to understand how a to turn a piece of software into unikernel when he / she finishes this project.<br />
<br />
Useful links:<br />
<br />
* http://rumpkernel.org/<br />
<br />
|Skills= Knowledge of operating system, GNU autotools, C programming and good debugging skills.<br />
<br />
|Outcomes=Patches for Xen and rump kernel.<br />
}}<br />
<br />
=== MirageOS ===<br />
<br />
{{project<br />
|Project=Various MirageOS Pioneer Projects<br />
|Date=01/30/2015<br />
|Verified=Feb 8th, 2015 (see this [http://lists.xenproject.org/archives/html/mirageos-devel/2015-02/msg00046.html conversation])<br />
|Contact=Send a mail to mirageos-devel@lists.xenproject.org if you're interested in starting on one or several of these projects. <br />
|Difficulty=Various levels of difficulty<br />
|Skills=OCaml<br />
|Desc=This is a list of pioneer projects for Mirage OS, covering area such as '''Build Tools''', '''New Libraries''', '''Storage Technologies''', '''Networking Technologies''', '''Interfaces to Non-Ocaml (aka foreign) Languages''' and other topics. Note that some of these projects may be too small or too big for a single GSoC project. If you are interested in one of these, make sure you discuss first on mirageos-devel@lists.xenproject.org - we can then merge or split these as needed for GSoC.<br />
<br />
References:<br />
* [https://github.com/mirage/mirage-www/wiki/Pioneer-Projects Complete list of Pioneer Projects]<br />
<br />
|GSoC=yes, but do check mirageos-devel@lists.xenproject.org first<br />
}}<br />
<br />
{{project<br />
|Project=Create a tiny VM for easy load testing<br />
|Date=01/30/2014<br />
|Verified=Feb 8th, 2015 (see this [http://lists.xenproject.org/archives/html/mirageos-devel/2015-02/msg00046.html conversation])<br />
|Contact=Dave Scott <dave.scott@eu.citrix.com><br />
|Difficulty=Medium<br />
|Skills=OCaml<br />
|Desc=The Mirage OS framework (see http://xenproject.org/developers/teams/mirage-os.html, http://www.openmirage.org/) can be used to create tiny 'unikernels': entire software stacks which run directly on the Xen hypervisor. These VMs have such a small memory footprint (16 MiB or less) that many of them can be run even on relatively small hosts. The goal of this project is to create a specific unikernel that can be configured to generate a specific I/O pattern, and to create configurations that mimic the boot sequence of Linux and Windows guests. The resulting unikernel will then enable cheap system load testing.<br />
<br />
The first task is to generate an I/O trace from a VM. For this we could use 'xen-disk', a userspace Mirage application which acts as a block backend for xen guests (see http://openmirage.org/wiki/xen-synthesize-virtual-disk). Following the wiki instructions we could modify a 'file' backend to log the request timestamps, offsets, buffer lengths.<br />
<br />
The second task is to create a simple kernel based on one of the MirageOS examples (see http://github.com/mirage/mirage-skeleton). The 'block' example shows how reads and writes are done. The previously-generated log could be statically compiled into the kernel and executed to generate load.<br />
|Outcomes=1. a repository containing an 'unikernel' (see http://github.com/mirage/mirage-skeleton)<br />
2. at least 2 I/O traces, one for Windows boot and one for Linux boot (any version)<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=Fuzz testing Xen with Mirage<br />
|Date=28/11/2013<br />
|Verified=Feb 8th, 2015 (see this [http://lists.xenproject.org/archives/html/mirageos-devel/2015-02/msg00046.html conversation])<br />
|Contact=Anil Madhavapeddy <anil@recoil.org><br />
|Skills=OCaml, Xen<br />
|Difficulty=medium<br />
|Desc=<br />
Mirage OS (see http://xenproject.org/developers/teams/mirage-os.html, http://www.openmirage.org/) is a type-safe unikernel written in OCaml which generates highly specialised "appliance" VMs that run directly on Xen without requiring an intervening guest kernel. We would like to use the Mirage/Xen libraries to fuzz test all levels of a typical cloud toolstack. Mirage has low-level bindings for Xen hypercalls, mid-level bindings for domain management, and high-level bindings to XCP for cluster management. This project would build a QuickCheck-style fuzzing mechanism that would perform millions of random operations against a real cluster, and identify bugs with useful backtraces.<br />
<br />
The first task would be to become familiar with a specification-based testing tool like Kaputt (see http://kaputt.x9c.fr/). The second task would be to choose an interface for testing; perhaps one of the hypercall ones.<br />
[[GSoC_2013#fuzz-testing-mirage]]<br />
|Outcomes=1. a repo containing a fuzz testing tool; 2. some unexpected behaviour with a backtrace (NB it's not required that we find a critical bug, we just need to show the approach works)<br />
|GSoC=yes<br />
}}<br />
<br />
{{project<br />
|Project=Mirage OS web stack testing<br />
|Date=25/02/2014<br />
|Verified=Feb 8th, 2015 (see this [http://lists.xenproject.org/archives/html/mirageos-devel/2015-02/msg00046.html conversation])<br />
|Contact=Anil Madhavapeddy <anil@recoil.org><br />
|Skills=OCaml, shell scripting<br />
|Difficulty=medium<br />
|Desc=<br />
MirageOS has an emerging web toolstack that's broken up as a series of libraries -- for example, Cohttp, Uri, Cow, Ipaddr, RSS and Cowabloga. This project will get you familiar with them by building a protocol testing framework that can generate traffic using off-the-shelf tools such as httperf, and evaluate the results vs applications such as Apache or Nginx.<br />
<br />
|Outcomes=1. a test harness for HTTP; 2. some results of the evaluation using the test harness<br />
|GSoC=yes<br />
}}<br />
<br />
== List of projects that need more work ==<br />
{{Anchor|Unreviewed Project Ideas}}<br />
<br />
=== Xen Hypervisor ===<br />
<br />
{{project<br />
|Project=Introducing PowerClamp-like driver for Xen<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
PowerClamp was introduced to Linux in late 2012 in order to allow users to set a system-wide maximum<br />
power usage limit. This is particularly useful for data centers, where there may be a need to<br />
reduce power consumption based on availability of electricity or cooling. A [http://lwn.net/Articles/528124/ more complete writeup]<br />
is available at LWN.<br />
<br />
These same arguments apply to Xen. The purpose of this project would be to implement a similar functionality in Xen,<br />
and to make it interface as well as possible with the Linux PowerClamp tools, so that the same tools could be used<br />
for both. [[GSoC_2013#powerclamp-for-xen]]<br />
|GSoC=Yes<br />
}}<br />
<br />
=== Xen Hypervisor Userspace Tools ===<br />
{{project<br />
|Project=Refactor Linux hotplug scripts<br />
|Date=15/11/2012<br />
|Contact=Roger Pau Monné <[mailto:roger.pau@citrix.com roger.pau@citrix.com]><br />
|Desc=<br />
Current Linux hotplug scripts are all entangled, which makes them really difficult to understand or modify. The reason of hotplug scripts is to give end-users the chance to "easily" support different configuration for Xen devices.<br />
<br />
Linux hotplug scripts should be analized, providing a good description of what each hotplug script is doing. After this, scripts should be cleaned, putting common pieces of code in shared files across all scripts. A Coding style should be applied to all of them when the refactoring is finished.<br />
<br />
[[GSoC_2013#linux-hotplug-scripts]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=XL to XCP VM motion<br />
|Date=15/11/12<br />
|Contact=[mailto:ian.campbell@citrix.com Ian Campbell]<br />
|Desc=Currently [[XL|xl]] (the toolstack supplied alongside Xen) and [[XAPI|xapi]] (the XCP toolstack) have very different concepts about domain configuration, disk image storage etc. In the XCP model domain configuration is persistent and stored in a data base while under xl domain configuration is written in configuration files. Likewise disk images are stored as VDIs in Storage Repositories while under xl disk images are simply files or devices in the dom0 filesystem. For more information on xl see [[XL]]. For more information on XCP see [[XCP Overview]].<br />
<br />
This project is to produce one or more command-line tools which support migrating VMs between these toolstacks.<br />
<br />
One tool should be provided which takes an xl configuration file and details of an XCP pool. Using the XenAPI XML/RPC interface It should create a VM in the pool with a close approximation of the same configuration and stream the configured disk image into a selected Storage Repository.<br />
<br />
A second tool should be provided which performs the opposite operation, i.e. give a reference to a VM residing in an XCP pool it should produce an XL compatible configuration file and stream the disk image(s) our of Xapi into a suitable format.<br />
<br />
These tools could be reasonably bundled as part of either toolstack and by implication could be written in either C, Ocaml or some other suitable language.<br />
<br />
The tool need not operate on a live VM but that could be considered a stretch goal.<br />
<br />
An acceptable alternative to the proposed implementation would be to implement a tool which converts between a commonly used VM container format which is supported by XCP (perhaps [http://en.wikipedia.org/wiki/Open_Virtualization_Format OVF] or similar) and the xl toolstack configuration file and disk image formats.<br />
<br />
[[GSoC_2013#xl-to-xcp-vm-motion]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Advanced Scheduling Parameters<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
The credit scheduler provides a range of "knobs" to control guest behavior, including CPU weight and caps. However,<br />
a number of users have requested the ability to encode more advanced scheduling logic. For instance, "Let this VM max out for 5 minutes out of any given hour; but after that, impose a cap of 20%, so that even if the system is idle he can't an unlimited amount of CPU power without paying for a higher level of service."<br />
<br />
This is too coarse-grained to do inside the hypervisor; a user-space tool would be sufficient. The goal of this project would<br />
be to come up with a good way for admins to support these kinds of complex policies in a simple and robust way.<br />
<br />
|GSoC=Yes<br />
}}<br />
<br />
<br />
<br />
=== PCI Pass-through improvements ===<br />
<br />
{{project<br />
|Project=Allowing guests to boot with a passed-through GPU as the primary display<br />
|Date=01/22/2013<br />
|Contact=George Dunlap <george.dunlap@eu.citrix.com><br />
|Desc=<br />
One of the primary drivers of Xen in the "consumer market" of the open-source world is the ability to<br />
pass through GPUs to guests -- allowing people to run Linux as their main desktop but easily play <br />
games requiring proprietary operating systems without rebooting.<br />
<br />
GPUs can be easily passed through to guests as secondary displays, but as of yet cannot be passed<br />
through as primary displays. The main reason is the lack of ability to load the VGA BIOS from the card into the guest.<br />
<br />
The purpose of this project would be to allow HVM guests to load the physical card's VGA bios, so that the guest can<br />
boot with it as the primary display.<br />
<br />
[[GSoC_2013#gpu-passthrough]]<br />
|GSoC=Yes<br />
}}<br />
<br />
{{project<br />
|Project=Improve PCIe Advanced Error Reporting (AER) handling for passed-through devices<br />
|Date=03/04/2014<br />
|Difficulty=Medium-High<br />
|Skills=Understanding of PC server hardware, PCIe, C<br />
|Contact=Matt Wilson <msw@amazon.com><br />
|Outcomes=Patches for libxl, qemu, and perhaps xen-pciback posted<br />
|Desc=Today the xen-pciback driver handles an AER event for passed-through PCI devices. If the device is assigned to a PV guest, it uses xenstore to request a reset from xen-pcifront. If the device is assigned to a HVM guest, the toolstack is notified and is expected to take corrective action.<br />
<br />
The toolstack support for taking corrective action is only implemented in [http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/python/xen/xend/server/pciif.py;h=27c1b75cfcf2695740e57bde557d2ee04c4d7322;hb=HEAD#l459 xend], not libxl. For HVM guests ideally, the AER event would be propagated into the guest through the device model (qemu) so that the driver inside the guest can take reset actions.<br />
<br />
|GSoC=Yes<br />
}}<br />
<br />
=== XAPI ===<br />
<br />
{{project<br />
|Project=DRBD Integration<br />
|Date=07/01/2013<br />
|Contact=John Morris <john@zultron.com><br />
|Desc=<br />
DRBD is potentially a great addition to the other high-availability features in XenAPI. An architecture of as few as two Dom0s with DRBD mirrored local storage is an inexpensive minimal HA configuration enabling live migration of VMs between physical hosts and providing failover in case of disk failure, and eliminates the need for external storage. This setup can be used in small shop or hobbyist environments, or could be used as a basic unit in a much larger scalable architecture.<br />
<br />
Existing attempts at integrating DRBD sit below the SM layer and thus do not enable one VBD per DRBD device. They also suffer from a split-brain situation that could be avoided by controlling active/standby status from XenAPI.<br />
<br />
DRBD should be implemented as a new SR type on top of LVM. The tools for managing DRBD devices need to be built into storage management, along with the logic for switching the active and standby nodes.<br />
}}<br />
<br />
== New Project Ideas ==<br />
{{Anchor|New_Project_Ideas}}<br />
'''Please add new project ideas here, following '''<br />
<br />
== Archive ==<br />
=== GSoC Projects that were accepted in 2014 ===<br />
<br />
{{project<br />
|Project=Implement Xen PVUSB support in xl/libxl toolstack<br />
|Date=01/12/2012<br />
|Contact=Mentor: George Dunlap, Student: Bo Cao<br />
|GSoC=Yes<br />
|Desc=<br />
xl/libxl does not currently support Xen PVUSB functionality. Port the feature from xm/xend to xl/libxl. Necessary operations include:<br />
* Task 1: Implement PVUSB in xl/libxl, make it functionally equivalent to xm/xend.<br />
* Send to xen-devel mailinglist for review, comments.<br />
* Fix any upcoming issues.<br />
* Repeat until merged to xen-unstable.<br />
* See above for PVUSB drivers for dom0/domU.<br />
* Xen PVUSB supports both PV domUs and HVM guests with PV drivers.<br />
* More info: http://wiki.xen.org/xenwiki/XenUSBPassthrough<br />
{{Comment|[[User:Lars.kurth|Lars.kurth]] 14:14, 23 January 2013 (UTC):}} Should be suitable, but desc needs. Rate in terms of challenges, size and skill. Also kernel functionality is not yet upstreamed. Maybe Suse kernel.<br />
}}<br />
<br />
{{project<br />
|Project=Lazy restore using memory paging<br />
|Date=01/20/2014<br />
|Contact=Mentor: Andres Lagar-Cavilla, Student: Dushyant Behl<br />
|Difficulty=Medium<br />
|GSoC=Yes<br />
|Desc=VM Save/restore results in a boatload of IO and non-trivial downtime as the entire memory footprint of a VM is read from IO.<br />
<br />
Xen memory paging support in x86 is now mature enough to allow for lazy restore, whereby the footprint of a VM is backfilled while the VM executes. If the VM hits a page not yet present, it is eagerly paged in.<br />
<br />
There has been some concern recently about the lack of docs and/or mature tools that use xen-paging. This is a good way to address the problem.<br />
<br />
|Skills= A good understanding of save/restore, and virtualized memory management (e.g. EPT, shadow page tables, etc). In principle the entire project can be implemented in user-space C code, but it may be the case that new hypercalls are needed for performance reasons.<br />
<br />
|Outcomes=Expected outcome:<br />
* Mainline patches for libxc and libxl<br />
}}<br />
<br />
{{project<br />
|Project=HVM per-event-channel interrupts<br />
|Date=01/30/2013<br />
|Contact=Mentor: Paul Durrant, Student: Yandong Han<br />
|Skills=C, some prior knowledge of Xen useful<br />
|Desc=Windows PV drivers currently have to multiplex all event channel processing onto a single interrupt which is registered with Xen using the HVM_PARAM_CALLBACK_IRQ parameter. This results in a lack of scalability when multiple event channels are heavily used, such as when multiple VIFs in the VM as simultaneously under load.<br />
<br />
Goal: Modify Xen to allow each event channel to be bound to a separate interrupt (the association being controlled by the PV drivers in the guest) to allow separate event channel interrupts to be handled by separate vCPUs. There should be no modifications required to the guest OS interrupt logic to support this (as there is with the current Linux PV-on-HVM code) as this will not be possible with a Windows guest.<br />
|Outcomes=Code is submitted to xen-devel@xen.org for inclusion in xen-unstable<br />
|GSoC=yes}}<br />
<br />
{{project<br />
|Project=Mirage OS cloud API support<br />
|Date=28/11/2013<br />
|Contact=Mentor: Dave Scott; Student: Jyotsna Prakash<br />
|Skills=OCaml<br />
|Difficulty=medium<br />
|Desc=<br />
MirageOS (see http://xenproject.org/developers/teams/mirage-os.html, http://www.openmirage.org/) is a type-safe unikernel written in OCaml which generates highly specialised "appliance" VMs that run directly on Xen without requiring an intervening kernel. A MirageOS application typically runs via several communicating kernel instances on the cloud. Today these instances are difficult to manage; we would like to explore strategies for managing these distributed computations using common public cloud APIs such as those exposed by Amazon EC2 and Rackspace.<br />
<br />
First we need to create pure OCaml API bindings for (e.g.) EC2 and Rackspace (purity is needed to ensure portability). These API bindings can then be used to provide operating-system-level abstractions to the unikernels. For example, a traditional VM might hotplug a vCPU; while a MirageOS application would request a "VM create" using the cloud API and "connect" the new instance to the existing network. We should be able to spin up 1000s of "CPUs" by using such APIs in a cluster environment.<br />
<br />
As well as helping Xen/Mirage, the public cloud API bindings will be very useful to other people in other contexts-- a nice side-effect.<br />
<br />
See https://fedoraproject.org/wiki/User:Gholms/EC2_Primer for a primer on how to use EC2<br />
|Outcomes=1. one or more public cloud API bindings plus examples, in a standalone repo on github; 2. an example mirage app which uses these APIs to spin up a new VM<br />
|GSoC=yes<br />
}}<br />
<br />
{{project<br />
|Project=Parallel xenwatch kthread<br />
|Date=01/08/2012<br />
|Difficulty=Low-Medium<br />
|Contact=Mentor: Boris Ostrovsky, Student: Tülin İZER<br />
|Desc=<br />
<br />
Xenwatch is locked with a coarse lock. For a huge number of guests this represents a scalability issue. The need is to rewrite the xenwatch locking in order to support full scalability.<br />
See https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/xen/xenbus/xenbus_xs.c#n768<br />
for the code.<br />
<br />
|Outcomes=Expected outcome:<br />
* Have upstream patches or a draft of them.<br />
* benchmark report of with and without.<br />
|GSoC=Yes<br />
| Skills=You need to have understanding of:<br />
* locks - spinlocks and mutexes<br />
* build Linux kernel<br />
}}<br />
<br />
== Conventions for Projects and Project Mentors == <br />
=== Rules and Advice for Adding Ideas ===<br />
* Be creative<br />
* Add projects into [[#New_Project_Ideas|New Project Ideas]] or improve projects in [[#Unreviewed Project Ideas|Project Ideas that Need Review or more work]] through review comments.<br />
* Use the {{tl|GSoC Project}} template to encode ideas on this page. Please read the [[Template:GSoC Project|Template Documentation]] before you do so.<br />
* 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<br />
* Check that the project meets the [[#Goals|GSoC Program Goals]]<br />
* If you are willing to mentors those ideas, add your name and email to the idea.<br />
* Aspiring mentors should introduce themselves on the most appropriate Xen Project mailing list<br />
<br />
=== Peer Review Goals ===<br />
We strongly recommend and invite project proposers and project mentors to review each others proposals. When you review, please look out for<br />
* Can a student get going and started with the information in the project description<br />
* Are any unstated assumptions in the proposal, is there undefined terminology, etc. in the proposal <br />
* Can the project completed in 3 months (assume that one month is needed for preparation)<br />
* {{Anchor|Goals}}Does the project meet Google Summer of Code goals, which are<br />
** Create and release open source code for the benefit of all<br />
** Inspire young developers to begin participating in open source development<br />
** Help open source projects identify and bring in new developers and committers <br />
** Provide students the opportunity to do work related to their academic pursuits (think "flip bits, not burgers")<br />
** Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)<br />
<br />
=== Peer Review Conventions ===<br />
The {{tl|GSoC Project}} template used to encode GSoC projects, contains some review functionality. Please read the [[Template:GSoC Project|Template Documentation]] before you add a template, also please use the conventions below to make comments.<br />
<br />
<pre><br />
|Review=(delete as addressed)<br />
* {{Comment|~~~~:}} Comment 1<br />
* {{Comment|~~~~:}} Comment 2<br />
</pre><br />
<br />
=== Choosing Projects ===<br />
We have a bi-weekly mentor meeting overlooked by our program management team, which are a core team of 2-3 mentors and a program administrator. This group will work with mentors to ensure that project proposals are of good quality and whether mentors are engaging with the program management team and students in the weeks before the application period ends. <br />
<br />
[[Category:GSoC]]<br />
[[Category:GSoC 2015]]<br />
[[Category:Developers]]<br />
[[Category:Index]]<br />
[[Category:Project]]<br />
[[Category:Transient]] <!-- as if not maintained it becomes stale --></div>Amirmchttps://wiki.xenproject.org/index.php?title=Mirage_Incubation_Project_Proposal&diff=5940Mirage Incubation Project Proposal2013-01-17T10:17:22Z<p>Amirmc: Add comment re xen-arm and link to mailing list message</p>
<hr />
<div>{{Info|This is a proposal that is for community review. If you have a comment, please add a comment using <pre>{{comment|~~~~}} Your comment.</pre> in the text. The proposal page contains a link to a PDF document, as well as in-lined text that can be commented on.}}<br />
<br />
= Document Information =<br />
== Process ==<br />
The community review process for the incubation project will follow version 1.2 of the [http://www.xen.org/projects/governance.html Xen Governance]<br />
== Time-table ==<br />
* Proposal will be open for feedback to the entire community until midnight on the 27th of Jan, 2013 (GMT)<br />
* Unless, significant changes to the proposal are made voting will be open until midnight of Feb3, 2013 (GMT). A mechanism for private voting amongst eligible community members will be made available in due course<br />
== Roles ==<br />
* '''Project Lead:''' Anil Madhavapeddy - Anil has led the Mirage project since its inception and would continue to do so during the incubation phase.<br />
* '''Project Sponsor:''' Tim Deegan - Tim is one of the maintainers of the Xen hypervisor and has agreed to act as Sponsor for this project. He was previously involved with a predecessor called Melange, which was published at the EuroSys conference in 2007 (paper available at: http://anil.recoil.org/papers/2007-eurosysmelange.pdf)<br />
* '''Project Mentor:''' Lars Kurth - Lars is the Community Manager for xen.org and has agreed to act and the project’s Mentor.<br />
<br />
== PDF Revisions == <br />
Revision history of proposals:<br />
* Initial version, Jan 10, 2013 : [[File:Mirage_Xen_Project_Proposal.pdf|v 1.0 of Proposal]]<br />
<br />
<br><br />
----<br />
<br />
= Mirage as a Xen.org incubated project =<br />
<br />
We propose to make Mirage an incubated project within Xen.org. This document<br />
aims to provide some background to Mirage and explain the relevance of Mirage<br />
to Xen (and the Xen Community).<br />
<br />
== Background - The aims of Mirage ==<br />
The cloud has so far mostly been used to consolidate existing operating systems<br />
and manage them more conveniently. The interface between guest kernels, applications<br />
and VMs are all managed very differently, leading to serious inefficiencies,<br />
unreliability and insecurity.<br />
<br />
Our Mirage OS revisits the library OS concept (built as Nemesis in the Cambridge<br />
Computer Lab in the late ’90s), and finds it a practical approach to improve<br />
this situation. Applications are written in a high-level functional programming<br />
language (OCaml) and compiled directly into microkernels that run on the Xen<br />
hypervisor. These microkernels can be treated as stand-alone appliances which<br />
use the Xen hypervisor interfaces directly.<br />
<br />
Treating the hypervisor as a stable hardware platform means we can focus on<br />
high-performance protocol implementations without worrying about having to<br />
support the thousands of device drivers found in a traditional OS.<br />
Mirage includes clean-slate functional implementations of protocols ranging from<br />
TCP/IP, DNS, SSH, Openflow (switch/controller), HTTP, XMPP and Xen<br />
inter-VM transports. Some of the new applications we are building using Mirage<br />
include the next-generation Xen Cloud Platform (a widely deployed open-source<br />
Xen distribution), dubbed Project Windsor.<br />
<br />
An example of a current Mirage appliance can be seen at http://openmirage.org, which<br />
is a self-hosted site deployed on the public cloud (in this case, on Amazon<br />
EC2). With some further work, it should also be possible to ‘encapsulate’ an<br />
existing piece of software using Mirage. One example might be to use Mirage to<br />
form an appliance from an existing Content Management System (e.g Drupal<br />
or Joomla). Such systems typically need several components and expect to be<br />
installed on a server. Mirage could be used to encapsulate a CMS, retaining only<br />
the components and bindings required by the CMS and removing the need for<br />
the rest of the Operating System. Such an appliance could be auto-configured<br />
and deployed directly to the public cloud (e.g. Rackspace or Amazon EC2).<br />
<br />
== Relevance to Xen and its Community ==<br />
<br />
Mirage has a very close dependency on the Xen hypervisor since it targets the<br />
hypervisor as a stable platform. As Mirage is written entirely in OCaml, a<br />
statically type-safe functional language, the resulting microkernels are protected<br />
against low-level memory errors, and made convenient to program via high-level<br />
interfaces. OCaml is also the implementation language for the XCP which makes<br />
integration with these components straightforward.<br />
<br />
Mirage produces microkernels that offer an order of magnitude reduction in code<br />
size and smaller VM memory footprints without significant performance penalty.<br />
The library-based architecture enables security, efficiency and performance optimisations,<br />
such as a single-address space that can be made immutable via an<br />
optional hypervisor extension (linked above), and compile-time configuration<br />
specialisation and inlining.<br />
<br />
The key insight is that the hypervisor provides a virtual hardware abstraction<br />
that can be scaled dynamically — vertically with memory and virtual CPUs, and<br />
horizontally by spawning more VMs. One benefit of this approach is the ability<br />
to make use of multicore. As everything runs over the Xen VMM, multicore<br />
is simply a case of running multiple instances of a given microkernel over Xen,<br />
communicating using the standard protocol stack.<br />
<br />
<br />
{{comment|[[User:Amirmc|Amirmc]] 10:17, 17 January 2013 (UTC)}} Re: Mirage and ARM (in response to an email comment). <br />
"We are indeed planning to support xen-arm,<br />
but are waiting for hardware. Dave and I both have Chromebooks A15 now,<br />
and we have patches floating around<br />
for HVM/x86_minios. An ARM PVHVM version should be quite straightforward.<br />
Another summer project I'm happy to supervise (particularly for GSoC) is a<br />
direct Raspberry Pi port, using uBoot as the main bootloader. That should<br />
shake out any ARM-specific issues in advance of a Xen/ARM port. Please get in<br />
touch with me if interested in this one."<br />
http://lists.xen.org/archives/html/xen-devel/2013-01/msg01105.html<br />
<br />
<br />
== Current status of Mirage ==<br />
Mirage has already been in development for over three years and a paper will be<br />
presented at an upcoming, top-tier conference, ASPLOS 2013. The paper will<br />
cover the technical background of the project as well as some of the evaluation.<br />
In the meantime, a previous paper is also available (see the HotCloud Paper<br />
of 2010). In addition, there are around 50 members on the current mailing list<br />
(view the archives) and a large body of code, which can be found on Github at<br />
https://github.com/mirage. Much work has been done to date on creating pure<br />
OCaml implementations of protocols, as listed previously.<br />
<br />
The existing maintainers will continue to work on Mirage while it is incubated<br />
at xen.org. Some of the people involved in Mirage include:<br />
* Anil Madhavapeddy, University of Cambridge - Technical Lead<br />
* Richard Mortier University of Nottingham - Project Lead at Horizon, Digital Economy Research<br />
* Dave Scott, Citrix Systems - Xen and Citrix<br />
* Thomas Gazagnaire, OCamlPro - Packaging<br />
* Jonathan Ludlam, Citrix Systems - Xen Cloud Platfom integration<br />
* Haris Rotsos, University of Cambridge - DNS implementation<br />
* Raphael Proust, University of Cambridge - Linear Typing<br />
* Balraj Singh, University of Cambridge - TCP/IP implementation<br />
* Gabor Pali, FreeBSD Core Team - FreeBSD kernel port<br />
* Robert Watson University of Cambridge - FreeBSD and MIPS/BERI<br />
<br />
== Interested parties and dependencies ==<br />
In addition to the current mailing<br />
list members and contributors, Citrix also has an interest. Mirage has been used<br />
internally during tests and benchmarking and there is continued support from<br />
key Citrix members to continue development (e.g Dave Scott).<br />
<br />
== Mirage during incubation ==<br />
The aim of making Mirage an incubated project is to raise its profile among the<br />
Xen community and draw more developers into contributing code and working<br />
towards a stable release. The current project has reached a stage where others can<br />
make use of the work to date and their input can accelerate the improvements and<br />
adoption of Mirage. In general, support from the Xen community is important to<br />
the long-term success of Mirage. Engagement from vendors such as Rackspace,<br />
Amazon, Citrix and others is also key.<br />
<br />
One of the things we hope to gain during incubation is to benefit from access<br />
to test infrastructure. This infrastructure will be used to test the build and<br />
deployment of Mirage as well as the packages it requires.<br />
<br />
The roles during incubation will be as follows:<br />
* '''Project Lead:''' Anil Madhavapeddy - Anil has led the Mirage project since its inception and would continue to do so during the incubation phase.<br />
* '''Project Sponsor:''' Tim Deegan - Tim is one of the maintainers of the Xen hypervisor and has agreed to act as Sponsor for this project. He was previously involved with a predecessor called Melange, which was published at the EuroSys conference in 2007 (paper available at: http://anil.recoil.org/papers/2007-eurosysmelange.pdf)<br />
* '''Project Mentor:''' Lars Kurth - Lars is the Community Manager for xen.org and has agreed to act as the project’s Mentor.<br />
<br />
== License ==<br />
The current codebase is released under the ISC license, with some code<br />
released under LGPLv2 (the Xen Cloud Platform). The ISC license is<br />
listed by the Open Source Initiative as one of their approved licences<br />
(http://opensource.org/licenses/ISC).<br />
As as example, Mirage code releases have a statement of the following form at<br />
the beginning of each file:<br />
<pre><br />
Copyright (c) 2011 Firstname Surname email@example.org<br />
Permission to use, copy, modify, and distribute this software for any<br />
purpose with or without fee is hereby granted, provided that the<br />
above copyright notice and this permission notice appear in all copies.<br />
THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR<br />
DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS<br />
SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF<br />
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL<br />
THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT,<br />
OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES<br />
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR<br />
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE<br />
OR OTHER TORTIOUS ACTION, ARISING OUT OF<br />
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF<br />
THIS SOFTWARE.<br />
</pre><br />
<br />
=== Rationale for Choice of License===<br />
Projects hosted on Xen.org, typically use GPLv2. In the case of Mirage it is necessary to use a permissive open source license such as "ISC" because Mirage based microkernels need to be statically linked with applications to form a stand-alone appliance. The use of the "ISC" license maximizes the number of applications that can be linked against and the use-cases that can thus be supported by Mirage. Further, "ISC" is compatible with "GNU GPL" licenses, which is required for Xen.org hosted incubation projects.<br />
<br />
[[Category:Project]]<br />
[[Category:Transient]]</div>Amirmchttps://wiki.xenproject.org/index.php?title=Mirage_Incubation_Project_Proposal&diff=5912Mirage Incubation Project Proposal2013-01-11T17:05:50Z<p>Amirmc: make mirage link clicky</p>
<hr />
<div>{{Info|This is a proposal that is for community review. If you have a comment, please add a comment using <pre>{{comment|~~~~}} Your comment.</pre> in the text. The proposal page contains a link to a PDF document, as well as in-lined text that can be commented on.}}<br />
<br />
= Document Information =<br />
== Process ==<br />
The community review process for the incubation project will follow version 1.2 of the [http://www.xen.org/projects/governance.html Xen Governance]<br />
== Time-table ==<br />
* Proposal will be open for feedback to the entire community until midnight on the 27th of Jan, 2013 (GMT)<br />
* Unless, significant changes to the proposal are made voting will be open until midnight of Feb3, 2013 (GMT). A mechanism for private voting amongst eligible community members will be made available in due course<br />
== Roles ==<br />
* '''Project Lead:''' Anil Madhavapeddy - Anil has led the Mirage project since its inception and would continue to do so during the incubation phase.<br />
* '''Project Sponsor:''' Tim Deegan - Tim is one of the maintainers of the Xen hypervisor and has agreed to act as Sponsor for this project. He was previously involved with a predecessor called Melange, which was published at the EuroSys conference in 2007 (paper available at: http://anil.recoil.org/papers/2007-eurosysmelange.pdf)<br />
* '''Project Mentor:''' Lars Kurth - Lars is the Community Manager for xen.org and has agreed to act and the project’s Mentor.<br />
<br />
== PDF Revisions == <br />
Revision history of proposals:<br />
* Initial version, Jan 10, 2013 : [[File:Mirage_Xen_Project_Proposal.pdf|v 1.0 of Proposal]]<br />
<br />
<br><br />
----<br />
<br />
= Mirage as a Xen.org incubated project =<br />
<br />
We propose to make Mirage an incubated project within Xen.org. This document<br />
aims to provide some background to Mirage and explain the relevance of Mirage<br />
to Xen (and the Xen Community).<br />
<br />
== Background - The aims of Mirage ==<br />
The cloud has so far mostly been used to consolidate existing operating systems<br />
and manage them more conveniently. The interface between guest kernels, applications<br />
and VMs are all managed very differently, leading to serious inefficiencies,<br />
unreliability and insecurity.<br />
<br />
Our Mirage OS revisits the library OS concept (built as Nemesis in the Cambridge<br />
Computer Lab in the late ’90s), and finds it a practical approach to improve<br />
this situation. Applications are written in a high-level functional programming<br />
language (OCaml) and compiled directly into microkernels that run on the Xen<br />
hypervisor. These microkernels can be treated as stand-alone appliances which<br />
use the Xen hypervisor interfaces directly.<br />
<br />
Treating the hypervisor as a stable hardware platform means we can focus on<br />
high-performance protocol implementations without worrying about having to<br />
support the thousands of device drivers found in a traditional OS.<br />
Mirage includes clean-slate functional implementations of protocols ranging from<br />
TCP/IP, DNS, SSH, Openflow (switch/controller), HTTP, XMPP and Xen<br />
inter-VM transports. Some of the new applications we are building using Mirage<br />
include the next-generation Xen Cloud Platform (a widely deployed open-source<br />
Xen distribution), dubbed Project Windsor.<br />
<br />
An example of a current Mirage appliance can be seen at http://openmirage.org, which<br />
is a self-hosted site deployed on the public cloud (in this case, on Amazon<br />
EC2). With some further work, it should also be possible to ‘encapsulate’ an<br />
existing piece of software using Mirage. One example might be to use Mirage to<br />
form an appliance from an existing Content Management System (e.g Drupal<br />
or Joomla). Such systems typically need several components and expect to be<br />
installed on a server. Mirage could be used to encapsulate a CMS, retaining only<br />
the components and bindings required by the CMS and removing the need for<br />
the rest of the Operating System. Such an appliance could be auto-configured<br />
and deployed directly to the public cloud (e.g. Rackspace or Amazon EC2).<br />
<br />
== Relevance to Xen and its Community ==<br />
<br />
Mirage has a very close dependency on the Xen hypervisor since it targets the<br />
hypervisor as a stable platform. As Mirage is written entirely in OCaml, a<br />
statically type-safe functional language, the resulting microkernels are protected<br />
against low-level memory errors, and made convenient to program via high-level<br />
interfaces. OCaml is also the implementation language for the XCP which makes<br />
integration with these components straightforward.<br />
<br />
Mirage produces microkernels that offer an order of magnitude reduction in code<br />
size and smaller VM memory footprints without significant performance penalty.<br />
The library-based architecture enables security, efficiency and performance optimisations,<br />
such as a single-address space that can be made immutable via an<br />
optional hypervisor extension (linked above), and compile-time configuration<br />
specialisation and inlining.<br />
<br />
The key insight is that the hypervisor provides a virtual hardware abstraction<br />
that can be scaled dynamically — vertically with memory and virtual CPUs, and<br />
horizontally by spawning more VMs. One benefit of this approach is the ability<br />
to make use of multicore. As everything runs over the Xen VMM, multicore<br />
is simply a case of running multiple instances of a given microkernel over Xen,<br />
communicating using the standard protocol stack.<br />
<br />
== Current status of Mirage ==<br />
Mirage has already been in development for over three years and a paper will be<br />
presented at an upcoming, top-tier conference, ASPLOS 2013. The paper will<br />
cover the technical background of the project as well as some of the evaluation.<br />
In the meantime, a previous paper is also available (see the HotCloud Paper<br />
of 2010). In addition, there are around 50 members on the current mailing list<br />
(view the archives) and a large body of code, which can be found on Github at<br />
https://github.com/mirage. Much work has been done to date on creating pure<br />
OCaml implementations of protocols, as listed previously.<br />
<br />
The existing maintainers will continue to work on Mirage while it is incubated<br />
at xen.org. Some of the people involved in Mirage include:<br />
* Anil Madhavapeddy, University of Cambridge - Technical Lead<br />
* Richard Mortier University of Nottingham - Project Lead at Horizon, Digital Economy Research<br />
* Dave Scott, Citrix Systems - Xen and Citrix<br />
* Thomas Gazagnaire, OCamlPro - Packaging<br />
* Jonathan Ludlam, Citrix Systems - Xen Cloud Platfom integration<br />
* Haris Rotsos, University of Cambridge - DNS implementation<br />
* Raphael Proust, University of Cambridge - Linear Typing<br />
* Balraj Singh, University of Cambridge - TCP/IP implementation<br />
* Gabor Pali, FreeBSD Core Team - FreeBSD kernel port<br />
* Robert Watson University of Cambridge - FreeBSD and MIPS/BERI<br />
<br />
== Interested parties and dependencies ==<br />
In addition to the current mailing<br />
list members and contributors, Citrix also has an interest. Mirage has been used<br />
internally during tests and benchmarking and there is continued support from<br />
key Citrix members to continue development (e.g Dave Scott).<br />
<br />
== Mirage during incubation ==<br />
The aim of making Mirage an incubated project is to raise its profile among the<br />
Xen community and draw more developers into contributing code and working<br />
towards a stable release. The current project has reached a stage where others can<br />
make use of the work to date and their input can accelerate the improvements and<br />
adoption of Mirage. In general, support from the Xen community is important to<br />
the long-term success of Mirage. Engagement from vendors such as Rackspace,<br />
Amazon, Citrix and others is also key.<br />
<br />
One of the things we hope to gain during incubation is to benefit from access<br />
to test infrastructure. This infrastructure will be used to test the build and<br />
deployment of Mirage as well as the packages it requires.<br />
<br />
The roles during incubation will be as follows:<br />
* '''Project Lead:''' Anil Madhavapeddy - Anil has led the Mirage project since its inception and would continue to do so during the incubation phase.<br />
* '''Project Sponsor:''' Tim Deegan - Tim is one of the maintainers of the Xen hypervisor and has agreed to act as Sponsor for this project. He was previously involved with a predecessor called Melange, which was published at the EuroSys conference in 2007 (paper available at: http://anil.recoil.org/papers/2007-eurosysmelange.pdf)<br />
* '''Project Mentor:''' Lars Kurth - Lars is the Community Manager for xen.org and has agreed to act and the project’s Mentor.<br />
<br />
== License ==<br />
The current codebase is released under the ISC license, with some code<br />
released under LGPLv2 (the Xen Cloud Platform). The ISC license is<br />
listed by the Open Source Initiative as one of their approved licences<br />
(http://opensource.org/licenses/ISC).<br />
As as example, Mirage code releases have a statement of the following form at<br />
the beginning of each file:<br />
<pre><br />
Copyright (c) 2011 Firstname Surname email@example.org<br />
Permission to use, copy, modify, and distribute this software for any<br />
purpose with or without fee is hereby granted, provided that the<br />
above copyright notice and this permission notice appear in all copies.<br />
THE SOFTWARE IS PROVIDED “AS IS” AND THE AUTHOR<br />
DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS<br />
SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF<br />
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL<br />
THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT,<br />
OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES<br />
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR<br />
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE<br />
OR OTHER TORTIOUS ACTION, ARISING OUT OF<br />
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF<br />
THIS SOFTWARE.<br />
</pre><br />
<br />
=== Rationale for Choice of License===<br />
Projects hosted on Xen.org, typically use GPLv2. In the case of Mirage it is necessary to use a permissive open source license such as "ISC" because Mirage based microkernels need to be statically linked with applications to form a stand-alone appliance. The use of the "ISC" license maximizes the number of applications that can be linked against and the use-cases that can thus be supported by Mirage. Further, "ISC" is compatible with "GNU GPL" licenses, which is required for Xen.org hosted incubation projects.<br />
<br />
[[Category:Project]]<br />
[[Category:Transient]]</div>Amirmc