Google Summer of Code 2011: Difference between revisions

From QEMU
(Surely implementing Firewire and XHCI doesn't require 68k assembler, right?)
(Add category)
 
(5 intermediate revisions by 5 users not shown)
Line 13: Line 13:


* [[User:LuizCapitulino|Luiz Capitulino]]
* [[User:LuizCapitulino|Luiz Capitulino]]
* [[User:Stefanha|Stefan Hajnoczi]]
* [[User:AnthonyLiguori|Anthony Liguori]]
* [[User:AnthonyLiguori|Anthony Liguori]]


Line 265: Line 266:
* Mentor: [[User:Agraf|Alexander Graf]]
* Mentor: [[User:Agraf|Alexander Graf]]
* Suggested by: [[User:Agraf|Alexander Graf]]
* Suggested by: [[User:Agraf|Alexander Graf]]
== IA64 emulation ==
'''Summary:''' Emulating the IA64 instruction set
Qemu implements all the of still-alive and soon-not-to-be-alive platforms out there, except for one! Itanium! We do have device emulation support for it in the qemu-kvm fork. There is [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome existing firmware] out there that even works with KVM on IA64. So all that's necessary to get people who don't have IA64 machines at home the fun of playing with it is CPU emulation code.
The project would start by getting an ia64-linux-user target rolling that can emulate IA64 Linux applications on other Linux systems. This will probably be enough of a scope for this GSoC.
* Component: Qemu
* Skill level: high
* Language: C, IA64 asm
* Mentor: [[User:Agraf|Alexander Graf]]? [[User:Aurel32|Aurelien Jarno]]? If anyone volunteers, I'll try to find someone who knows IA64 :)
* Suggested by: [[User:Agraf|Alexander Graf]]
[[Category:GSoC]]

Latest revision as of 15:07, 16 February 2016

Introduction

As we did last year, QEMU is going to apply as a mentoring organization for Google Summer of Code 2011. This page contains our ideas list and some additional information for students and mentors.

Please note that QEMU, as a GSoC organization, also includes the following projects:

  • The Linux Kernel's KVM module
  • Libvirt, the virtualization library (pending OK from libvirt people)

Organization

Any Question, request or problem regarding QEMU on GSoC 2011, please contact one of the following people.

Find Us

GSoC important pages

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

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

Projects Ideas

This is the listing of suggested project ideas. It might be useful to check last year's page. Also note that students are free to suggest their own projects.

QCOW2 <-> QED image converter

Summary: Design and implement an in-place disk image converter that safely and efficiently changes between the QCOW2 and QED image formats.

QEMU supports several disk image formats that make it possible to manage and share virtual machine disk images as files. The well known formats include qcow2 (QEMU) and vmdk (VMware), and the QEMU Enhanced Disk (QED) format has pushed new levels of performance.

In order for users to go between formats, the qemu-img convert command reads a disk image in one format and outputs it in another format. This has two limitations:

  1. Twice the amount of space is required since both the old and the new image are kept around.
  2. Copying data is slow for large images.

The aim is to design a safe in-place converter to change from QCOW2 to QED (and vice versa) without copying image data. This will require understanding the QCOW2 and QED image formats and how they organize image data. You will need to carefully design the process so image data is never at risk in the event of a crash during conversion. Finally, you will be responsible for adding tests that defend this feature to the qemu-iotests suite.

Links:

Please get in touch before applying so we can arrange for an IRC interview and get to know each other. Students who do not contact the mentor cannot be accepted for this project idea.

  • Component: QEMU
  • Skill level: medium
  • Language: C
  • Mentor: Stefan Hajnoczi <stefanha@gmail.com>, 'stefanha' on IRC
  • Suggested by: Stefan Hajnoczi <stefanha@gmail.com>

Improved image format compatibility

Summary: Add support for the latest versions of popular image formats.

There are a number of disk image formats in common use today. The qemu-img tool already supports the popular image formats. Some formats have evolved since their original support was added and new files cannot be accessed with qemu-img.

The aim is to address the lag in image format support by understanding the latest formats and implementing their new layouts in QEMU. This will enable qemu-img, qemu-io, and qemu-nbd to operate on an even wider range of disk images.

Links:

Please get in touch before applying so we can arrange for an IRC interview and get to know each other. Students who do not contact the mentor cannot be accepted for this project idea.

  • Component: QEMU
  • Skill level: medium
  • Language: C
  • Mentor: Stefan Hajnoczi <stefanha@gmail.com>, Kevin Wolf <kwolf@redhat.com>
  • Suggested by: Stefan Hajnoczi <stefanha@gmail.com>

Tracepoint support for the gdbstub

Recent gdb versions allow to define ad-hoc tracepoints that are able to record memory content or register states whenever the target code hits them. This is supposed to happen non-intrusively, while the target is executing (almost) as normal. QEMU could serve as a nice backend for gdb when it comes to using such dynamic tracepoints for (guest) kernel debugging. In contrast to approaches like kgtp running inside the guest kernel, QEMU is able to perform this in hypervisor context, at most requiring to insert breakpoints into guest visible memory.

In this project, the QEMU gdbstub shall be extended with support for tracepoints. Architecture specific parts shall at least support x86 guests. Tracepoints shall be usable both in emulation and KVM mode. Extending the KVM kernel services to accelerate tracepoints is not required in this first step. See gdb documentation and specifically the gdb remote protocol for further details.

  • Component: QEMU
  • Skill level: medium..high
  • Language: C
  • Mentor: Jan Kiszka <jan.kiszka@web.de>
  • Suggested by: Jan Kiszka <jan.kiszka@web.de>

Upstreaming EHCI support

There exists a good foundation for EHCI support in out-of-tree repository. But it hasn't been proposed for merge yet due to a few open issues. The list below reflects potential sub-tasks but it's not necessarily up-to-date with latest development:

  • testing and stabilizing host pass-through of various devices
  • periodic frames support
  • isochronous traffic support
  • split transactions support
  • improving NAK/reload support
  • throttle interrupt rate based on OS settings
  • code cleanup

The primary goal of this task is to fix the most annoying issues of the EHCI emulation and prepare the result of upstream merge.

  • Component: QEMU
  • Skill level: medium..high
  • Language: C
  • Mentor: Natalia Portillo, any other welcome
  • Suggested by: Jan Kiszka <jan.kiszka@web.de>

Improving USB emulation accuracy

There are still a few rough edges in QEMU's USB support beyond the EHCI topic:

  • improve USB device emulation like mass storage devices, network adapters, etc.
  • improved topology configuration by modeling it via qdev
  • new device emulations, e.g. webcam (playing video files) or IO-warrior-like device
  • ...

The task consists of identifying open issues and use cases by testing them against various guest systems, then fixing the deficits, and proposing the result in form of patch series for upstream merge.

  • Component: QEMU
  • Skill level: medium..high
  • Language: C
  • Mentor: Natalia Portillo, any other welcome
  • Suggested by: Jan Kiszka <jan.kiszka@web.de>

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 <jan.kiszka@web.de>
  • Suggested by: Jan Kiszka <jan.kiszka@web.de>

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).

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).

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.

  • Skill level: medium
  • Languages: C, ARM assembler
  • Mentor: tbd (Paul Brook proposed himself on GSoC 2010)
  • Suggested by: Natalia Portillo

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.

Upstream and clean-up of USB Video Class device emulation

On mid-2010 I implemented a webcam emulation (passthrough) using USB Video Class on the guest and Video4Linux on the host. The code was RFC to the mailing list and needs a couple of clean ups to be integrated mainstream. Once cleaned up, it needs to get implemented multiple resolution, image formats and isochronous transfers. Desirable is also adding support for Win32 (using WIA or VFW) and Mac OS X hosts.

Implementation of FireWire OHCI

Implementing a FireWire OHCI emulation will allow us to passthrough FireWire devices (mass storage, tape devices, video devices, IPo1394), or to emulate that devices from different host devices.

FireWire extensively uses DMA and should be as easy to implement as USB protocol, without the issues of the bulk mode of USB protocol.

Implementation of USB 3.0 XHCI

USB 3.0 gives better support for virtualization, and also unlike EHCI does not request the presence of previous generation controllers (EHCI, OHCI, UHCI) for handling previous generation devices (USB 2.0, USB 1.x).

This requires also taking in account Gerd patches for multiple speeds support on existing USB devices.

Virtagent Windows guest support

Summary: Create a virtagent compatible guest agent for Windows operating systems.

Virtagent is a host/guest communication protocol that is designed to enable easier and more reliable guest management. An RPC channel is created over either a virtio-serial or isa-serial device. Various commands are implemented such as: shutdown, ping and file retrieval. Currently, only Linux guests are supported. In order to make virtagent a more universal management interface, it should be supported on other operating systems (including Windows). This task can be broken down into the following activities:

  • virtio-serial support for Windows
  • Base Windows client support (Windows service programming / virtagent transport protocol implementation)
  • Implement RPC functions (OS Shutdown, file transfers, filesystem freeze/thaw, etc)
  • Windows package / installer

Applicants will need to have experience with Windows system programming.

  • Component: QEMU
  • Skill level: medium
  • Language: C
  • Mentor: Adam Litke <agl@us.ibm.com>, 'aglitke' on IRC
  • Suggested by: Adam Litke <agl@us.ibm.com>

KVM for Mac OS X hosts

Summary: Port KVM code to Mac OS X to run hardware accelerated qemu on Mac OS X

KVM provides a pretty simple interface for userspace applications like qemu to run virtual machines. There's no reason (except for the license) it should be limited to Linux kernel code though. We could wrap the Linux KVM code around some helpers that provide Linux functionality on XNU - the Mac OS X kernel. That would enable qemu to run virtual machines on Mac OS X hosts.

Applicants will need to have understanding of the XNU kernel and a broad grasp of KVM's kernel interfaces.

IA64 emulation

Summary: Emulating the IA64 instruction set

Qemu implements all the of still-alive and soon-not-to-be-alive platforms out there, except for one! Itanium! We do have device emulation support for it in the qemu-kvm fork. There is existing firmware out there that even works with KVM on IA64. So all that's necessary to get people who don't have IA64 machines at home the fun of playing with it is CPU emulation code.

The project would start by getting an ia64-linux-user target rolling that can emulate IA64 Linux applications on other Linux systems. This will probably be enough of a scope for this GSoC.

Retrieved from "https://wiki.qemu.org/index.php?title=Google_Summer_of_Code_2011&oldid=5309"