Archived/GSoc 2014: Difference between revisions
Lars.kurth (talk | contribs) No edit summary |
Lars.kurth (talk | contribs) No edit summary |
||
Line 115: | Line 115: | ||
* In particular, domain should be able to boot from the 9P FS. |
* In particular, domain should be able to boot from the 9P FS. |
||
}} |
}} |
||
⚫ | |||
{{InfoLeft|The ones below need work and will be moved into unreviewed, if not improved}} |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |Desc=NUMA (Non-Uniform Memory Access) systems are advanced server platforms, comprising multiple ''nodes''. Each node contains processors and memory. An advanced memory controller allows a node to use memory from all other nodes, but that happens, data transfer is slower than accessing local memory. Memory access times are not uniform and depend on the location of the memory and the node from which it is accessed, hence the name. |
||
⚫ | Trascendent memory (Tmem) can be seen as a mechanism for discriminating between frequently and infrequently used data, and thus helping allocating them properly. It would be interesting to investigate and implement all the necessary mechanisms to take advantage of this and improve performances of Tmem enabled guests running on NUMA machines. |
||
⚫ | For instance, implementing something like <code>alloc_page_on_any_node_but_the_current_one()</code> (or <code>any_node_except_this_guests_node_set()</code> for multinode guests), and have Xen's Tmem implementation use it (especially in combination with selfballooning), could solve a significant part of the NUMA problem when running Tmem-enabled guests. |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |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. |
||
⚫ | 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. |
||
⚫ | |||
⚫ | |||
=== Xen Hypervisor Userspace Tools === |
=== Xen Hypervisor Userspace Tools === |
||
Line 439: | Line 398: | ||
|GSoC=Yes, but we would have to chop them into smaller chunks working with the applicant |
|GSoC=Yes, but we would have to chop them into smaller chunks working with the applicant |
||
}} |
}} |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |Desc=NUMA (Non-Uniform Memory Access) systems are advanced server platforms, comprising multiple ''nodes''. Each node contains processors and memory. An advanced memory controller allows a node to use memory from all other nodes, but that happens, data transfer is slower than accessing local memory. Memory access times are not uniform and depend on the location of the memory and the node from which it is accessed, hence the name. |
||
⚫ | Trascendent memory (Tmem) can be seen as a mechanism for discriminating between frequently and infrequently used data, and thus helping allocating them properly. It would be interesting to investigate and implement all the necessary mechanisms to take advantage of this and improve performances of Tmem enabled guests running on NUMA machines. |
||
⚫ | For instance, implementing something like <code>alloc_page_on_any_node_but_the_current_one()</code> (or <code>any_node_except_this_guests_node_set()</code> for multinode guests), and have Xen's Tmem implementation use it (especially in combination with selfballooning), could solve a significant part of the NUMA problem when running Tmem-enabled guests. |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |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. |
||
⚫ | 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. |
||
⚫ | |||
⚫ | |||
== Conventions for Projects and Project Mentors == |
== Conventions for Projects and Project Mentors == |
Revision as of 01:47, 14 February 2014
The Xen Project is a Linux Foundation collaborative project that develops the
- Xen Hypervisor (for x86 and ARM)
- The XAPI toolstack
- Mirage OS
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.
GSoC and Xen
This page is used to list project ideas for Google Summer of Code (GSOC) 2014.
Key GSoC resources
Google Summer of Code 2014 is On (see [1]). The Xen Project has applied as a Mentoring Organization. Stay posted.
Finding a project that fits you
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?
To work on a project:
- Find a project that looks interesting (or a bug if you want to start with something simple)
- Send an email to the relevant mailing list (see Developer Mailing Lists) and let us know if you are interested in starting to work or applying on a specific project.
- Post your ideas, questions, RFCs to the relevant mailing list sooner than later so you can get comments and feedback.
You have your own project idea: no problem!
- 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 mailing list. Failing that post on xen-devel and we can redirect you to the right list. Make sure you add GSoC 2014 to the subject line.
It is a good idea to ...
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:
- Contact your mentor early and get to know him or her
- 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)
- 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 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.
- 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.
- 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.
More resources
Quick links to changelogs of the various Xen related repositories/trees: Please see XenRepositories wiki page!
Before to submit patches, please look at Submitting Xen Patches wiki page and the relevant Xen Project team page. This will contain more information.
If you have new ideas, suggestions or development plans let us know and we'll update this list!
Applying for GSoC
![]() |
Note that we will update this section when more student information on 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. |
To apply for a project, follow the steps outlined on
- melange
- We do have our own GSoC Student Application Template form
List of peer reviewed Projects
Domain support (PVOPS and Linux)
OVMF Compatibility Support Module support in Xen
|
Parallel xenwatch kthread
|
Utilize Intel QuickPath on network and block path.
|
Enabling the 9P File System transport as a paravirt device
|
Xen Hypervisor Userspace Tools
CPU/RAM/PCI diagram tool
|
KDD (Windows Debugger Stub) enhancements
|
Refactor Linux hotplug scripts
|
XL to XCP VM motion
|
VM Snapshots
|
Allowing guests to boot with a passed-through GPU as the primary display
|
Advanced Scheduling Parameters
|
Lazy restore using memory paging
|
CPUID Programming for Humans
|
Mirage OS
Create a tiny VM for easy load testing
|
Fuzz testing Xen with Mirage
|
Mirage OS cloud API support
|
XAPI
DRBD Integration
|
List of projects that need more work
Domain support (PVOPS and Linux)
Implement Xen PVSCSI support in xl/libxl toolstack
|
Implement Xen PVUSB support in xl/libxl toolstack
|
Block backend/frontend improvements
|
Xen Hypervisor
Introducing PowerClamp-like driver for Xen
|
Integrating NUMA and Tmem
|
HVM per-event-channel interrupts
|
Conventions for Projects and Project Mentors
Rules and Advice for Adding Ideas
- Be creative
- Add projects into Project Ideas that Need Review or more work.
- Use the {{GSoC Project}} template to encode ideas on this page. Please read the Template Documentation before you do so.
- 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
- Check that the project meets the GSoC Program Goals
- If you are willing to mentors those ideas, add your name and email to the idea.
- If you're an interested student, add your name and email next to the idea. It is ok to have several students interested by one idea.
- Aspiring students need to get in touch with the xen.org community manager via community.manager@xen.org to register their interest
Peer Review Goals
We strongly recommend and invite project proposers and project mentors to review each others proposals. When you review, please look out for
- Can a student get going and started with the information in the project description
- Are any unstated assumptions in the proposal, is there undefined terminology, etc. in the proposal
- Can the project completed in 3 months (assume that one month is needed for preparation)
- Does the project meet Google Summer of Code goals, which are
- Create and release open source code for the benefit of all
- Inspire young developers to begin participating in open source development
- Help open source projects identify and bring in new developers and committers
- Provide students the opportunity to do work related to their academic pursuits (think "flip bits, not burgers")
- Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)
Peer Review Conventions
The {{GSoC Project}} template used to encode GSoC projects, contains some review functionality. Please read the Template Documentation before you add a template, also please use the conventions below to make comments.
|Review=(delete as addressed) * {{Comment|~~~~:}} Comment 1 * {{Comment|~~~~:}} Comment 2