I recently got a few requests for new project ideas; here is a short list of some options that Ian Pratt thought might be interesting:
1. Xen will soon be including the openflow vswitch developed under the openvswitch.org project. In order to integrate support for SR-IOV network hardware, we need a special kind of bond driver in the guest that initially routes traffic via the vswitch, but then can receive instructions from the vswitch to route individual flows to the direct hardware path (falling back to the normal software path via the vswitch if the SR-IOV VF gets unplugged).
2. Build on some of the existing work done in Cambridge to use Tungsten Graphics Gallium as a device-independent and API-independent 3D remoting protocol.
3. Get the blkback/netback drivers working in a HVM guest, effectively allowing domain0 to optionally be a HVM guest.
4. Fully implement domain0 restartability, effectively enabling a dom0 reboot or upgrade without rebooting the rest of the system. (There’s been plenty of work done on this already, but it needs finishing off)
5. investigate how a hypervisor could best use large amount of NAND FLASH memory. (not just via a disk API, but as native FLASH)
6. Deterministic replay for xen. (see the University of Michigan papers).
7. work on the ARM xen port to get it to the same level as the x86 port
8. implement UBC Remus for HVM guests and integrate it into the main Xen tree.
9. virtualize a GPU in a device-dependent fashion (everyone has been doing it in a device-independent fashion, but there may be big performance and fidelity wins to be had doing it in a device-specific fashion). Since the Intel GPU drivers are open source it should be possible to do this on Intel GPUs.
10. Extend Cambridge/UBC Parallax to implement content-addressable hashing to save disk space
11. Switch the PV SCSI over to using the netchannel2 ring protocol for improved performance.
