Google Summer of Code 2018

From QEMU
Revision as of 15:45, 9 January 2018 by Stefanha (talk | contribs)

Introduction

QEMU is applying for Google Summer of Code 2018. This page contains our ideas list and information for students and mentors. Google Summer of Code is a program that pays students for 12-week full-time remote work on open source projects from May to August!

Students: Google has not published the list of accepted organizations yet. You are welcome to contribute to QEMU and contact mentors for project ideas you are interested in. Please keep in mind that QEMU may not be accepted into GSoC to avoid disappointment.

Application Process

After contacting the mentor to discuss the project idea you should fill out the application form at [1]. The form asks for a problem description and outline of how you intend to implement a solution. You will need to do some background research (looking at source code, browsing relevant specifications, etc) in order to form an idea of how to tackle the project. The form asks for an initial 12-week project schedule which you should create by breaking down the project into tasks and estimating how long they will take. The schedule can be adjusted during the summer so don't worry about getting everything right ahead of time.

Candidates may be invited to an IRC interview with the mentor. The interview consists of a 30 minute C coding exercise, followed by technical discussion and a chance to ask questions you have about the project idea, QEMU, and GSoC. The coding exercise is designed to show fluency in C programming.

Here is a C coding exercise we have used in previous years when interviewing students: 2014 coding exercise

Try it and see if you are comfortable enough writing C. We cannot answer questions about the previous coding exercise but hopefully it should be self-explanatory.

If you find the exercise challenging, think about applying to other organizations where you have a stronger technical background and will be more competitive compared with other candidates.

Find Us

  • IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
  • IRC (development):
    • QEMU: #qemu on irc.oftc.net
    • KVM: #kvm on chat.freenode.net

Please contact the mentor for the project idea you are interested in. IRC is usually the quickest way to get an answer.

For general questions about QEMU in GSoC, please contact the following people:

Project Ideas

This is the listing of suggested project ideas. Students are free to suggest their own projects, see #How to propose a custom project idea below.

micro:bit machine type

Summary: Add emulation support for the micro:bit board

The micro:bit is a small computer for educational use that is also suitable for embedded and Internet of Things (IoT) projects. It uses a 16 MHz ARM Cortex-M0 processor with 256 KB flash and 16 KB RAM. It features many I/O capabilities including a 5x5 LED display, 2 buttons, Bluetooth and Nordic Gazell radio communications, an accelerometer, a compass, temperature and light sensing, UART, and GPIO pins for external devices.

This project will add micro:bit emulation support to QEMU, allowing code written with the Python and Javascript Blocks editors to run on your computer. Baremetal code not written with the official editors, such as C/C++ code using the microbit-dal runtime, will also work since QEMU emulates a full system including CPU and hardware devices.

This project involves:

  1. Implementing ARM Cortex-M0 CPU support based on existing Cortex-M3 support in QEMU
  2. Implementing a micro:bit .hex ROM loader
  3. Implementing a "microbit" machine type
  4. Implementing at least the 5x5 LED display, buttons, and UART.
  5. Stubbing out other devices as needed for the runtime to start successfully.

The goal is to run "Hello World!" programs created with the Python and Javascript Blocks editors. If you have time it may be possible to implement additional hardware devices or a graphical user interface.

Previous experience with low-level systems software (firmware, bootloaders, kernels) and hardware (Arduino, PIC, microcontrollers) is recommended. Start by looking at the reference design schematic to understand how the micro:bit works.

Links:

Details:

  • Skill level: advanced
  • Language: C
  • Mentors: Stefan Hajnoczi <stefanha@gmail.com> ('stefanha' on IRC), Jim Mussared <jim@groklearning.com>, Joel Stanley <joel@jms.id.au>

Separate process for UI

Summary: Run QEMU UI in a separate process

Normally, if QEMU is compiled with graphical window support, it displays output such as guest graphics, guest console, and the QEMU monitor in a window.

On the other hand, there are remote display viewers, such as remote-viewer that provide similar functionalities for user interactions and desktop integration. There is a duplication of effort to provide a good experience on the various OS & desktops over time.

With the SPICE protocol, there shouldn't be a performance hit, since the compression is disabled locally and the display process may use shared buffers/textures.

However, some functions are lacking, such as QEMU monitor interactions or console support. They can be provided thanks to SPICE "port" channel for example. Other mechanisms or solutions are possible (for example, quit QEMU when the display process exit by watching the child process). In other cases, virt-viewer provides a superior experience: clipboard sharing, usb hotplugging, kiosk mode, custom key bindings, shared folders, advanced display configuration, etc.

The goal of this summer of code is to provide a new -display backend to run a "QEMU UI" in a seperate process. It should try to provide as much functionality as the existing display backends.

For example, a -display spice backend that would run an enhanced remote-viewer as child process, with additional menu entries and terminal consoles providing a similar experience as -display gtk.

Links:

Details:

  • Skill level: intermediate or advanced
  • Language: C
  • Mentors: marcandre.lureau@redhat.com, kraxel@redhat.com
  • Suggested by: marcandre.lureau@redhat.com

virgl on Windows host

Summary: make virgl rendering work on Windows host

virgl enables accelerated 3d rendering in a VM. It requires Desktop GL on the host.

In theory, virgl should work on Windows with a capable host driver. This project aim at making virgl work well with various GPU on Windows. Since many Windows OpenGL drivers have bad behaviours, it would be worth to support ANGLE/opengles instead. This would require various modifications in virgl library. Additionally, it would be a good opportunity to ease the cross-compilation and packaging of qemu/virgl with msitools.

Links:

Details:

  • Skill level: intermediate or advanced
  • Language: C
  • Mentors: marcandre.lureau@redhat.com, airlied@redhat.com
  • Suggested by: marcandre.lureau@redhat.com

Vulkan-ize virgl

Summary: accelerated rendering of Vulkan APIs

virgl enables accelerated 3d rendering in a VM. It uses Desktop GL on host, and provides OpenGL/GLES in guest.

This project would aim at implementing Vulkan accelerated rendering. There are multiple ways of interpreting this idea. One interesting approach would be to support Vulkan in VM on a Vulkan-capable host, doing more passthrough.

Links:

Details:

  • Skill level: advanced
  • Language: C
  • Mentors: airlied@redhat.com, marcandre.lureau@redhat.com
  • Suggested by: marcandre.lureau@redhat.com

Project idea template

=== TITLE ===
 
 '''Summary:''' Short description of the project
 
 Detailed description of the project.
 
 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites
 
 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

How to propose a custom project idea

Applicants are welcome to propose their own project ideas. The process is as follows:

  1. Email your project idea to qemu-devel@nongnu.org. CC Stefan Hajnoczi <stefanha@gmail.com> and regular QEMU contributors who you think might be interested in mentoring.
  2. If a mentor is willing to take on the project idea, work with them to fill out the "Project idea template" above and email Stefan Hajnoczi <stefanha@gmail.com>.
  3. Stefan will add the project idea to the wiki.

Note that other candidates can apply for newly added project ideas. This ensures that custom project ideas are fair and open.

How to get familiar with our software

See what people are developing and talking about on the mailing lists:

Grab the source code or browse it:

Build QEMU and run it: QEMU on Linux Hosts

Important links

Information for mentors

Mentors are responsible for keeping in touch with their student and assessing the student's progress. GSoC has a mid-term evaluation and a final evaluation where both the mentor and student assess each other.

The mentor typically gives advice, reviews the student's code, and has regular communication with the student to ensure progress is being made.

Being a mentor is a significant time commitment, plan for 5 hours per week. Make sure you can make this commitment because backing out during the summer will affect the student's experience.

The mentor chooses their student by reviewing student application forms and conducting IRC interviews with candidates. Depending on the number of candidates, this can be time-consuming in itself. Choosing the right student is critical so that both the mentor and the student can have a successful experience.

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