Google Summer of Code 2010: Difference between revisions

From QEMU
No edit summary
(add gsoc category)
 
(40 intermediate revisions by 10 users not shown)
Line 1: Line 1:
This is a page for collecting ideas to present to Google Summer of Code 2010.
= Introduction =
 
QEMU has been accepted as a mentoring organization for [http://socghop.appspot.com/ Google Summer of Code 2010]! You can visit our organization profile [http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/qemu here].
 
= Organization =
 
Any problem, question or request regarding QEMU projects on GSoC 2010, please contact one of the following people.
 
* [[User:LuizCapitulino|Luiz Capitulino]]
* [[User:AnthonyLiguori|Anthony Liguori]]
* [[User:NataliaPortillo|Natalia Portillo]]
* [[User:BrianJackson|Brian Jackson]]
* [[User:pbrook|Paul Brook]]
 
= Find Us =
 
* IRC (devel): #qemu on irc.freenode.net
* IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
* Mailing list: http://lists.nongnu.org/mailman/listinfo/qemu-devel
 
= Information for students =
 
We require students to provide (at least) the following information in their applications:
 
* Contact information (email, irc nick, phone number)
* A general personal description (skills, past experiences and possible open source contributions)
* Why QEMU and why this project
* A detailed description of the approach the student will take
 
'''IMPORTANT:''' Submitting a patch and having it merged by QEMU or KVM increases your chances of being accepted.
 
= GSoC important pages =
 
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Dates]
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/userguide User Guide]
* [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs FAQ]
* [http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors Advice for Mentors]


= Projects Ideas =
= Projects Ideas =
This is the listing of suggested project ideas, but students are free to suggest their own projects.


== Convert Monitor commands to the QObject API ==
== Convert Monitor commands to the QObject API ==


In order to support different types of output (eg. user Monitor and a machine protocol), we have introduced a object layer to QEMU. Every monitor command should be converted to use the API provided by that layer (called the QObject API), currently we have several commands still to be converted.
In order to support different types of output (eg. user Monitor and a [http://www.linux-kvm.org/page/MonitorProtocol machine protocol]), we have introduced an object layer to QEMU. Every monitor command should be converted to use the API provided by that layer (called the QObject API), currently we have several commands still to be converted.
 
* Skill level: medium
* Language: C
* Mentor: [[User:LuizCapitulino|Luiz Capitulino]] / Markus Armbruster
* Suggested by: [[User:LuizCapitulino|Luiz Capitulino]]
 
== Improve/Simplify the QObject API ==
 
In order to support different types of output (eg. user Monitor and a [http://www.linux-kvm.org/page/MonitorProtocol machine protocol]), we have introduced an object layer to QEMU. This object layer has an API, called the QObject API. Currently it is too low-level and doesn't provide good debugging functionality.


* Skill level: medium
* Skill level: medium
* Language: C
* Language: C
* Mentor: [[User:LuizCapitulino|LuizCapitulino]]
* Mentor: [[User:LuizCapitulino|Luiz Capitulino]] / Markus Armbruster
* Suggested by: [[User:LuizCapitulino|LuizCapitulino]]
* Suggested by: [[User:LuizCapitulino|Luiz Capitulino]]
 
== Improve error handling in Monitor handlers ==
 
QEMU handlers implement Monitor commands. Several of those handlers use functions which print data to a fixed location (say standard error) which is wrong, as the Monitor output maybe graphical for example. Some functions don't do any error check at all, others will just abort(). Additionally, most of them have to be converted to the QError API.
 
* Skill level: medium
* Language: C
* Mentor: [[User:LuizCapitulino|Luiz Capitulino]] / Markus Armbruster
* Suggested by: [[User:LuizCapitulino|Luiz Capitulino]]
 
== Add AHCI emulation to QEMU ==
 
Newer Windows versions run in Qemu only with IDE emulation which is very slow. Writing virtio drivers is also difficult because drivers for those Windows versions needs to be signed. An alternative is to implement a device emulation which fits better to virtualization needs. AHCI has one of those device interfaces and is currently not emulated by Qemu. Goal of this project is to implement an AHCI emulation for Qemu.
 
* Skill level: high
* Languages: C
* Mentor: [[User:joro|Jörg Rödel]], [[User:Agraf|Alexander Graf]]
* Suggested by: [[User:joro|Jörg Rödel]]


== Add Macintosh to 68k system emulation ==
== Add Macintosh to 68k system emulation ==


* Skill level:
In order to support Macintosh system emulation, almost every device must be implemented on QEMU (SCSI, CUDA, ADB, Apple framebuffers). How they work can be investigated in Inside Macintosh documents and other emulators (MESS, BasiliskII, vMac).
* Languages:
 
* Mentor:
* Skill level: high
* Languages: C, 68k assembler
* Mentor: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]


== Boot Mac OS X (x86 and x86-64) without hacking it ==
== Mac guest machine support (x86) ==


* Skill level:
In order to boot Mac OS X for Intel architectures an ICH-7 chipset needs to be emulated. The biggest missing part is SATA emulation (AHCI).
* Languages:
 
* Mentor:
* Skill level: high
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
* Languages: C
* Mentor: [[User:Agraf|Alexander Graf]]
* Suggested by: [[User:Agraf|Alexander Graf]]
 
== Mac-on-Linux guest machine support (ppc) ==
 
The Mac-on-Linux project has a working paravirtual device collection, firmware and bootloader to make Mac OS X work inside Mac-on-Linux. With this device set ported to Qemu, we could obsolete the Mac-on-Linux project as is and use TCG and KVM as backends.
 
* Skill level: high
* Languages: C
* Mentor: [[User:Agraf|Alexander Graf]]
* Suggested by: [[User:Agraf|Alexander Graf]]
 
== G3/G4 KVM host support ==
 
I'm not sure this is the right place to put this. If not, please mark it as invalid.
 
KVM for PowerPC supports G5 hosts today. To fully deprecate the Mac-on-Linux kernel module, we'd need to get PPC32 host support too.
 
* Skill level: high
* Languages: C, PPC Assembler
* Mentor: [[User:Agraf|Alexander Graf]]
* Suggested by: [[User:Agraf|Alexander Graf]]


== Boot Mac OS >= 8.5 on PowerPC system emulation ==
== Boot Mac OS >= 8.5 on PowerPC system emulation ==


(Toolbox is included with system so no need for Mac's ROM dump)
Most of Power Macintosh hardware is emulated, things need only to be cleaned and OpenBIOS enhanced to support loading Macintosh Toolbox from the "Mac OS ROM" file present in any Mac OS >= 8.5 system.


* Skill level:
* Skill level: medium
* Languages:
* Languages: C, Forth
* Mentor:
* Mentor: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]


== Add a more common VGA, like the S3 Trio ==
== Add a S3 Trio or S3 Virge ==


(more guests have native drivers for that card than for Cirrus GD5446)
More x86 guests have native drivers for that card than for Cirrus GD5446. It was also used for a lot of non-x86 machines (like IBM workstations and servers).


* Skill level:
* Skill level: medium
* Languages:
* Languages: C, x86 assembler
* Mentor:
* Mentor:
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
Line 46: Line 135:
== Enhance, update and integrate Acorn Archimedes system emulation ==
== Enhance, update and integrate Acorn Archimedes system emulation ==


(it was available for 0.9.0 or so)
ARM system emulation should include Acorn Archimedes system emulation. Work-In-Progress was done against 0.9.0 tree. Now with Risc OS open sourced things could be easier. Most problems seems to be rarely used opcodes and 26-bit modes.


* Skill level:
* Skill level: medium
* Languages:
* Languages: C, ARM assembler
* Mentor:
* Mentor: [[User:pbrook|Paul Brook]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]


== BeBox system emulation ==
== BeBox system emulation ==


* Skill level:
The BeBox system is just a CHRP compliant dual PowerPC 603 processor machine. Most of the devices are already emulated, only a couple need to be added. Original firmware can be reverse engineered as it is a very simple firmware (not OpenFirmware compliant).
* Languages:
 
* Mentor:
* Skill level: medium
* Languages: C, maybe PowerPC assembler
* Mentor: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]


== NeXT machines system emulation ==
== NeXT machines system emulation ==


* Skill level:
NeXT machines are designed in a similar idea to 68k Macintosh ones. Documentation is almost not available. Original firmware MUST be used. MESS emulator project started a NeXT emulation but it is still work-in-progress so not much ideas can be taken from it.
* Languages:
 
* Mentor:
* Skill level: high
* Languages: C, 68k assembler
* Mentor: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]
* Suggested by: [[User:NataliaPortillo|Natalia Portillo]]


== Shared memory transport between guest(s) and host ==
== Shared memory transport between guest(s) and host ==


* Skill level:
The goal of this project is create a shared memory transport between guest VMs (and the host) that is exposed up to the user-level to allow for application-specific zero-copy communication.  Synchronization mechanisms will be provided via eventfd notifications (and using ioeventfds in the KVM case).  This requires the creation of a Qemu PCI device that can map a POSIX memory object from the host into the guest.  To support multiple guests, a shared memory server will pass eventfd and shared memory file descriptors to each guest using SCM_RIGHTS.
* Languages:
 
* Mentor:
* Skill level: medium
* Languages: C
* Mentor: Avi Kivity
* Suggested by: Cam Macdonell
* Suggested by: Cam Macdonell


== Pass through file systems (9p, CIFS) ==
== Pass through file systems (9p, CIFS) ==


* Skill level:
The goal of this project would be to produce a seamless user experience sharing a portion of the host file system with the guest.  This could focus on a number of technologies.  We could provide better support within QEMU to expose a Samba-based CIFS mount to a guest.  This would involve modifications to Samba to allow all of the port traffic to be tunneled over a unix domain socket so that TCP ports on the host were not needed.  It would also involve a small bit of Windows code to automatically use network shares on a special interface.  Finally, it would involve adding code to QEMU to plumb all of this together.
* Languages:
 
* Mentor:
Another possibility is to focus on taking the recent virtio-9p support and providing a better user experience with it.  This would involve auto mount code within the guest to discover and automatically configure special types of virtio-9p mounts.
 
* Skill level: medium
* Languages: C
* Mentor: [[User:AnthonyLiguori|Anthony Liguori]]
* Suggested by: Cam Macdonell
* Suggested by: Cam Macdonell


== Add more sophisticated encodings to VNC server ==
== Add more sophisticated encodings to VNC server ==


* Skill level:
QEMU's built-in VNC server only supports the Hextile encoding.  Hextile only uses tile-based compression.  Other encodings are more popular such as Tight and ZRLE that use zlib-based compression.  These encodings significantly reduce the bandwidth required by VNC.  This project would start by implementing support for Tight or ZRLE.  Both encodings support a combination of tile-based compression and zlib-compression.  Initially, one would implement zlib-compression only and compare the results to our Hextile implementation.  Depending on progress, tile-based compression mechanisms (such as Tight's gradient algorithm) could be explored.  At each stage, we expect that performance comparisons are done to determine the effectiveness of the additional algorithm.  Additional compression mechanisms like Tight's JPEG encoding could also be evaluated.
* Languages:
 
* Mentor:
* Skill level: low-medium
* Languages: C
* Mentor: [[User:AnthonyLiguori|Anthony Liguori]], [[User:Agraf|Alexander Graf]]
* Suggested by: [[User:AnthonyLiguori|Anthony Liguori]]
* Suggested by: [[User:AnthonyLiguori|Anthony Liguori]]


== Write a C QMP library based on QEMU JSON and QMP code ==
== Write a C QMP library based on QEMU JSON and QMP code ==


* Skill level:
As of QEMU 0.12.0, we expose a new JSON based management interface called QMP.  We would like to also ship a library for interacting with that interface as part of QEMU.  This project would involve taking the JSON parsing and QObject code and separating it out into a shared library.  It would also involve implementing a higher level API based on this code that exposes each of the QMP functions.
* Languages:
 
* Mentor:
* Skill level: medium
* Languages: C
* Mentor: [[User:Paolo Bonzini|Paolo Bonzini]]
* Suggested by: [[User:AnthonyLiguori|Anthony Liguori]]
* Suggested by: [[User:AnthonyLiguori|Anthony Liguori]]


== Add support for guest copy/paste ==
== Add support for guest copy/paste ==


* Skill level:
For QEMU 0.13.0, we will support a special communications channel between the host and guest based on virtio-serial.  One goal of this channel is to implement features like transparent copy/paste support between the host and guest.  This project would involve writing a daemon that runs in the guest that uses a well known virtio-serial port to implement a copy/paste proxy.  It would also involve implementing host-side support in QEMU via the VNC server.  Initially, the project would focus on a GTK-based implementation for Unix systems but depending on progress, it could also involve implementing a Windows copy/paste daemon.
* Languages:
 
* Mentor:
* Skill level: medium
* Languages: C (Win32, GTK)
* Mentor: [[User:AnthonyLiguori|Anthony Liguori]]
* Suggested by: [[User:AnthonyLiguori|Anthony Liguori]]
* Suggested by: [[User:AnthonyLiguori|Anthony Liguori]]


Ideas by Jan Kiszka:
== Device state visualization ==
* Device state visualization (savevm-based capturing, pretty-printing infrastructure, support for popular devices)
 
* Upstreaming some of the Android emulator bits
For debugging guest access to emulated hardware, it can be very useful to obtain the state of those devices. The idea is to make use of QEMU's infrastructure to freeze devices for snapshots/migrations, but write that snapshots in a human-readable form to the monitor interface. Besides plain dumping of known variables, there should also be a way to add pretty-printing for key information of individual devices, like translated flag bits, visualized queue content, etc.


* Skill level: medium
* Languages: C
* Mentor: Jan Kiszka
* Suggested by: Jan Kiszka
== Upstreaming some of the Android emulator bits  ==
The Android Emulator is based on ancient QEMU. To kick off its upstream integration, the existing code shall be analyzed and core elements of the emulated reference platform shall be ported to current QEMU. The goal is to get some Android image booting, bringing it into a usable state so that simple applications can be tested.
* Skill level: medium..high
* Languages: C
* Mentor: Jan Kiszka
* Suggested by: Jan Kiszka
== Completing big real mode emulation  ==
* Skill level: high
* Languages: C, x86 assembly
* Mentor: Avi Kivity
* Suggested by: Avi Kivity
== IOMMU emulation ==
Modern computers come with an IOMMU, which assists in assigning host devices to virtualized guests.  An emulated IOMMU, in conjunction with svm emulation or kvm's nested svm, can be used for assigning guest or even host devices to nested guests.  This can improve performance and greatly aid with automated testing.
* Skill level: high
* Languages: C
* Mentor: [[User:AnthonyLiguori|Anthony Liguori]], [[User:joro|Joerg Roedel]]
* Suggested by: Avi Kivity
== VNC server coroutine ==
Our builtin VNC server is implemented as a combination of a pure state machine to allow scalability.  The VNC protocol is very complex though and this implementation is difficult to follow as a result.  This project would convert to the existing server to be implemented as a cooperatively scheduled thread in the style of a coroutine.  Time permitting, a pure coroutine implementation using ucontext could be implemented.  Also, given sufficient progress, one could pursue running the VNC server thread in parallel with the QEMU IO thread in order to achieve better overall scalability.
* Skill level: medium-to-high
* Languages: C
* Mentor: [[User:AnthonyLiguori|Anthony Liguori]]
* Suggested by: [[User:AnthonyLiguori|Anthony Liguori]]


Mentors
[[Category:GSoC]]
* Brian Jackson
** IRC Nick: iggy
** Areas Of Specialty: Jack of all trades
** I'm not a hardcore qemu dev, but I know my way around, I know who knows what, my time is probably less valuable than some of the other devs, and I have the available time to do it
* Natalia Portillo
** IRC Nick: claunia
** I'm not a qemu developer but I have the most extensive collection of guests systems for testing, access to a couple of hardware and lots of documentation.

Latest revision as of 15:02, 16 February 2016

Introduction

QEMU has been accepted as a mentoring organization for Google Summer of Code 2010! You can visit our organization profile here.

Organization

Any problem, question or request regarding QEMU projects on GSoC 2010, please contact one of the following people.

Find Us

Information for students

We require students to provide (at least) the following information in their applications:

  • Contact information (email, irc nick, phone number)
  • A general personal description (skills, past experiences and possible open source contributions)
  • Why QEMU and why this project
  • A detailed description of the approach the student will take

IMPORTANT: Submitting a patch and having it merged by QEMU or KVM increases your chances of being accepted.

GSoC important pages

Projects Ideas

This is the listing of suggested project ideas, but students are free to suggest their own projects.

Convert Monitor commands to the QObject API

In order to support different types of output (eg. user Monitor and a machine protocol), we have introduced an object layer to QEMU. Every monitor command should be converted to use the API provided by that layer (called the QObject API), currently we have several commands still to be converted.

Improve/Simplify the QObject API

In order to support different types of output (eg. user Monitor and a machine protocol), we have introduced an object layer to QEMU. This object layer has an API, called the QObject API. Currently it is too low-level and doesn't provide good debugging functionality.

Improve error handling in Monitor handlers

QEMU handlers implement Monitor commands. Several of those handlers use functions which print data to a fixed location (say standard error) which is wrong, as the Monitor output maybe graphical for example. Some functions don't do any error check at all, others will just abort(). Additionally, most of them have to be converted to the QError API.

Add AHCI emulation to QEMU

Newer Windows versions run in Qemu only with IDE emulation which is very slow. Writing virtio drivers is also difficult because drivers for those Windows versions needs to be signed. An alternative is to implement a device emulation which fits better to virtualization needs. AHCI has one of those device interfaces and is currently not emulated by Qemu. Goal of this project is to implement an AHCI emulation for Qemu.

Add Macintosh to 68k system emulation

In order to support Macintosh system emulation, almost every device must be implemented on QEMU (SCSI, CUDA, ADB, Apple framebuffers). How they work can be investigated in Inside Macintosh documents and other emulators (MESS, BasiliskII, vMac).

Mac guest machine support (x86)

In order to boot Mac OS X for Intel architectures an ICH-7 chipset needs to be emulated. The biggest missing part is SATA emulation (AHCI).

Mac-on-Linux guest machine support (ppc)

The Mac-on-Linux project has a working paravirtual device collection, firmware and bootloader to make Mac OS X work inside Mac-on-Linux. With this device set ported to Qemu, we could obsolete the Mac-on-Linux project as is and use TCG and KVM as backends.

G3/G4 KVM host support

I'm not sure this is the right place to put this. If not, please mark it as invalid.

KVM for PowerPC supports G5 hosts today. To fully deprecate the Mac-on-Linux kernel module, we'd need to get PPC32 host support too.

Boot Mac OS >= 8.5 on PowerPC system emulation

Most of Power Macintosh hardware is emulated, things need only to be cleaned and OpenBIOS enhanced to support loading Macintosh Toolbox from the "Mac OS ROM" file present in any Mac OS >= 8.5 system.

Add a S3 Trio or S3 Virge

More x86 guests have native drivers for that card than for Cirrus GD5446. It was also used for a lot of non-x86 machines (like IBM workstations and servers).

  • Skill level: medium
  • Languages: C, x86 assembler
  • Mentor:
  • Suggested by: Natalia Portillo

Enhance, update and integrate Acorn Archimedes system emulation

ARM system emulation should include Acorn Archimedes system emulation. Work-In-Progress was done against 0.9.0 tree. Now with Risc OS open sourced things could be easier. Most problems seems to be rarely used opcodes and 26-bit modes.

BeBox system emulation

The BeBox system is just a CHRP compliant dual PowerPC 603 processor machine. Most of the devices are already emulated, only a couple need to be added. Original firmware can be reverse engineered as it is a very simple firmware (not OpenFirmware compliant).

NeXT machines system emulation

NeXT machines are designed in a similar idea to 68k Macintosh ones. Documentation is almost not available. Original firmware MUST be used. MESS emulator project started a NeXT emulation but it is still work-in-progress so not much ideas can be taken from it.

Shared memory transport between guest(s) and host

The goal of this project is create a shared memory transport between guest VMs (and the host) that is exposed up to the user-level to allow for application-specific zero-copy communication. Synchronization mechanisms will be provided via eventfd notifications (and using ioeventfds in the KVM case). This requires the creation of a Qemu PCI device that can map a POSIX memory object from the host into the guest. To support multiple guests, a shared memory server will pass eventfd and shared memory file descriptors to each guest using SCM_RIGHTS.

  • Skill level: medium
  • Languages: C
  • Mentor: Avi Kivity
  • Suggested by: Cam Macdonell

Pass through file systems (9p, CIFS)

The goal of this project would be to produce a seamless user experience sharing a portion of the host file system with the guest. This could focus on a number of technologies. We could provide better support within QEMU to expose a Samba-based CIFS mount to a guest. This would involve modifications to Samba to allow all of the port traffic to be tunneled over a unix domain socket so that TCP ports on the host were not needed. It would also involve a small bit of Windows code to automatically use network shares on a special interface. Finally, it would involve adding code to QEMU to plumb all of this together.

Another possibility is to focus on taking the recent virtio-9p support and providing a better user experience with it. This would involve auto mount code within the guest to discover and automatically configure special types of virtio-9p mounts.

  • Skill level: medium
  • Languages: C
  • Mentor: Anthony Liguori
  • Suggested by: Cam Macdonell

Add more sophisticated encodings to VNC server

QEMU's built-in VNC server only supports the Hextile encoding. Hextile only uses tile-based compression. Other encodings are more popular such as Tight and ZRLE that use zlib-based compression. These encodings significantly reduce the bandwidth required by VNC. This project would start by implementing support for Tight or ZRLE. Both encodings support a combination of tile-based compression and zlib-compression. Initially, one would implement zlib-compression only and compare the results to our Hextile implementation. Depending on progress, tile-based compression mechanisms (such as Tight's gradient algorithm) could be explored. At each stage, we expect that performance comparisons are done to determine the effectiveness of the additional algorithm. Additional compression mechanisms like Tight's JPEG encoding could also be evaluated.

Write a C QMP library based on QEMU JSON and QMP code

As of QEMU 0.12.0, we expose a new JSON based management interface called QMP. We would like to also ship a library for interacting with that interface as part of QEMU. This project would involve taking the JSON parsing and QObject code and separating it out into a shared library. It would also involve implementing a higher level API based on this code that exposes each of the QMP functions.

Add support for guest copy/paste

For QEMU 0.13.0, we will support a special communications channel between the host and guest based on virtio-serial. One goal of this channel is to implement features like transparent copy/paste support between the host and guest. This project would involve writing a daemon that runs in the guest that uses a well known virtio-serial port to implement a copy/paste proxy. It would also involve implementing host-side support in QEMU via the VNC server. Initially, the project would focus on a GTK-based implementation for Unix systems but depending on progress, it could also involve implementing a Windows copy/paste daemon.

Device state visualization

For debugging guest access to emulated hardware, it can be very useful to obtain the state of those devices. The idea is to make use of QEMU's infrastructure to freeze devices for snapshots/migrations, but write that snapshots in a human-readable form to the monitor interface. Besides plain dumping of known variables, there should also be a way to add pretty-printing for key information of individual devices, like translated flag bits, visualized queue content, etc.

  • Skill level: medium
  • Languages: C
  • Mentor: Jan Kiszka
  • Suggested by: Jan Kiszka

Upstreaming some of the Android emulator bits

The Android Emulator is based on ancient QEMU. To kick off its upstream integration, the existing code shall be analyzed and core elements of the emulated reference platform shall be ported to current QEMU. The goal is to get some Android image booting, bringing it into a usable state so that simple applications can be tested.

  • Skill level: medium..high
  • Languages: C
  • Mentor: Jan Kiszka
  • Suggested by: Jan Kiszka

Completing big real mode emulation

  • Skill level: high
  • Languages: C, x86 assembly
  • Mentor: Avi Kivity
  • Suggested by: Avi Kivity

IOMMU emulation

Modern computers come with an IOMMU, which assists in assigning host devices to virtualized guests. An emulated IOMMU, in conjunction with svm emulation or kvm's nested svm, can be used for assigning guest or even host devices to nested guests. This can improve performance and greatly aid with automated testing.

VNC server coroutine

Our builtin VNC server is implemented as a combination of a pure state machine to allow scalability. The VNC protocol is very complex though and this implementation is difficult to follow as a result. This project would convert to the existing server to be implemented as a cooperatively scheduled thread in the style of a coroutine. Time permitting, a pure coroutine implementation using ucontext could be implemented. Also, given sufficient progress, one could pursue running the VNC server thread in parallel with the QEMU IO thread in order to achieve better overall scalability.