Google Summer of Code 2023: Difference between revisions

From QEMU
No edit summary
Line 71: Line 71:
{{:Internships/ProjectIdeas/RDPServer}}
{{:Internships/ProjectIdeas/RDPServer}}
{{:Internships/ProjectIdeas/VirtioSound}}
{{:Internships/ProjectIdeas/VirtioSound}}
{{:Internships/ProjectIdeas/SVQOptimization}}


== Project idea template ==
== Project idea template ==

Revision as of 00:37, 7 February 2023

Introduction

QEMU is applying for Google Summer of Code 2023. This page contains our ideas list and information for applicants and mentors. Google Summer of Code is an open source internship program offering paid remote work.

Status: Google will announce accepted organizations on February 22 at 18:00 UTC. Applicants may get in touch with mentors now but please don't invest too much time until Google officially announces participating organization.

Application Process

1. Discuss the project idea with the mentor(s)

Read the project ideas list and choose one you are interested in. Read the links in the project idea description and start thinking about how you would approach this. Ask yourself:

  • Do I have the necessary technical skills to complete this project?
  • Will I be able to work independently without the physical presence of my mentor?

If you answer no to these questions, choose another project idea and/or organization that fits your skills.

Once you have identified a suitable project idea, email the mentor(s) your questions about the idea and explain your understanding of the project idea to them to verify that you are on the right track.

2. Fill out the application form

The application 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 decide how to tackle the project. The form asks for an initial 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.

3. Interview including a coding exercise

You may be invited to an interview consisting of a 30-minute 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 the programming language for your project idea (QEMU projects are typically in C but could also be in Python or Rust).

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

Try it and see if you can complete the sample coding exercise comfortably. We cannot answer questions about the previous coding exercise but hopefully it should be self-explanatory.

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

Key Dates

From the timeline:

  • February 22 18:00 UTC - Organizations and project ideas announced
  • March 20 - April 4 18:00 UTC - Application period
  • May 4 18:00 UTC - Accepted applicants announced
  • May 29 - August 28 - Standard coding period (an extended timeline is possible depending on your project)

Find Us

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.

Under Construction

How to add a project idea

  1. Create a new wiki page under "Internships/ProjectIdeas/YourIdea" and follow #Project idea template.
  2. Add a link from this page like this: {{:Internships/ProjectIdeas/YourIdea}}

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.

Native Library Calls

Summary: Implement a native bypass for when a program running under linux-user calls a well known library call

When running under linux-user we translate the whole program which includes all the library calls. A number of well understood library functions are usually fairly heavily optimised for the processor they run on. For example the semantics of memcpy are very well understood. We could consider instead of translating those library functions call to native versions of the code. As the runtime of library functions is generally biased to a few core functions only a small subset would need to be hooked to be useful (mem*, str*).

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate with a good understanding of how linkers link to library calls
  • Language: C
  • Mentor: Alex Bennée (alex.bennee@linaro.org)
  • Suggested by: Alex Bennée

Rust bindings for libnbd

Summary: Add Rust bindings for libnbd

Network block device (NBD) is a protocol for exporting block devices (disk-like things) between processes, either across the network or between processes on the same machine. libnbd is a client library and some tools for talking to NBD servers. This library has bindings in various languages such as Python, but not in Rust, and the project is about writing those bindings.

Note that the bindings in libnbd are generated. You must add Rust bindings to the generator so that they are updated automatically as the libnbd API evolves in future. Simply addng Rust bindings for the current API will not be enough to complete the project. The Rust bindings must also be of high quality and natural for Rust developers to use. Documentation and tests are also required.

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate or advanced
  • Language: C, Rust, OCaml
  • Mentor: rjones@redhat.com rwmjones on IRC
  • Suggested by: Richard Jones

RDP server

Summary: An out-of-process RDP server using `-display dbus`

QEMU can export its display via D-Bus since 7.0. The interface is close to the QEMU-internal API and offers display, audio, inputs, chardev, usb... Among other projects using it, a gtk4 client is in development (qemu-rdw), helping some applications such as GNOME Boxes, to port their code.

It's also interesting to use the interface to export the display on the network, using existing protocols, like VNC, Spice, or RDP. For example, and as a starting point perhaps, there is already an experimental VNC server written 100% Rust.

RDP being the most supported protocol, with more features and efficiency, this project idea is to develop a RDP server to export `-display dbus` over the network. Ideally, the project should be written in Rust. Unfortunately, IronRDP, the RDP crate, is lacking some server support. Investments in IronRDP is thus required. Alternatively, the project could be written in C (or other languages) with FreeRDP.

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate (familiarity with RDP would be a big plus)
  • Languages: C, Rust
  • Mentor: Marc-André Lureau - marcandre.lureau@redhat.com - elmarco
  • Suggested by: Marc-André Lureau

Update (2024-02-17): a vhost-user sound device has been implemented in the rust-vmm project. QEMU supports it through the vhost-user-snd and vhost-user-snd-pci devices (commit 4ae0fc18a1dc91bfe3a494292faf3c4c1b2cc16c)

Implement virtio-sound emulation as a Rust vhost-user back-end

Summary: Implement device emulation for the new virtio-sound device.

The VIRTIO specification defines a sound device and Linux has a guest driver for it, but QEMU does not emulate the virtio-sound device yet.

The goal is to implement virtio-sound emulation with mono and stereo playback and capture support. The code should be developed as a vhost-user back-end (a standalone program that communicates with QEMU) using the Rust vhost-user and gstreamer crates. The vhost crate handles the interfacing with QEMU and the low-level VIRTIO details. The gstreamer crate is a cross-platform multimedia API that abstracts the native audio API (ALSA, CoreAudio, etc).

As stretch goals you can implement additional functionality covered by the VIRTIO sound device specification, including support for multi-channel devices (e.g. surround sound playback), channel maps, etc. If you have even more time you can implement QEMU dbus-display support for streaming audio over remote desktop connections (for remote viewers like VNC/RDP/Spice).

To familiarize yourself with the project idea (see links below):

  1. Review the VIRTIO sound device specification.
  2. Review the vhost-user crate's vhost-user-backend module and the gstreamer crate.
  3. Review the unfinished patches for an idea of how to implement the device in C.

Intermediate Rust programming skills are required for this project. This project will expose you to device emulation, VIRTIO, and you'll learn how audio devices work at the hardware interface level.

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate/advanced
  • Language: Rust
  • Mentor: Stefan Hajnoczi <stefanha@redhat.com>, Alex Bennée <alex.bennee@linaro.org>
  • Suggested by: Gerd Hoffmann <kraxel@redhat.com>

Shadow Virtqueue performance optimization

Summary: Implement multithreading and mmap Queue Notifier optimizations for Shadow Virtqueues

To perform a virtual machine live migration, QEMU needs to know when devices modify memory so that the memory contents can be migrated each time they have been modified. Otherwise the virtual machine would resume with outdated memory and probably crash.

This is especially difficult with passthrough hardware devices because QEMU does not intercept the memory writes. As a method to overcome this for virtio devices, QEMU can present an emulated virtqueue to the device, called a Shadow Virtqueue (SVQ), instead of allowing the device to access guest memory directly. SVQ will then forward the writes to the guest, being the effective writer of the guest memory and knowing when a portion of it needs to be migrated again.

As this effectively breaks passthrough and adds extra steps in the communication, this comes with a performance penalty in several forms: Context switches, more memory reads and writes increasing cache pressure, etc.

At this moment the SVQ code is not optimized. It cannot forward buffers in parallel using multiqueue and multithreading, and it does not use the mmap Queue Notify mechanism to notify the device for available buffers efficiently, so these notifications need to perform an extra host kernel context switch.

The SVQ code requires modifications for multithreading. There are examples of multithreaded devices already, like virtio-blk, which can be used as a template. Proposals for a command-line syntax to map virtqueues to threads have been sent to QEMU mailing list already and you can use them.

Regarding the mmap Queue Notify optimization, QEMU already has code to set up the Queue Notify address for a vDPA device in vhost_vdpa_host_notifier_init(). At the moment the SVQ code doesn't make use of this yet. The SVQ code needs to write into the mmap region to avoid the more expensive event_notifier_set() call in vhost_svq_kick().

Your goal is the complete the following tasks:

  • Measure SVQ performance compared to non-SVQ with standard profiling tools like netperf (TCP_STREAM & TCP_RR) or iperf equivalent + DPDK's testpmd with AF_PACKET.
  • Add multithreading to SVQ, extracting the code from the Big QEMU Lock (BQL)
  • Add mmap Queue Notify support to vhost_svq_kick().

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate
  • Languages: C
  • Mentor: Eugenio Perez Martin <eperezma@redhat.com> (eperezma on IRC)
  • Suggested by: Eugenio Perez Martin <eperezma@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

Links

Information for mentors

Mentors are responsible for keeping in touch with their intern and assessing progress. GSoC has evaluations where both the mentor and intern assess each other.

The mentor typically gives advice, reviews the intern's code, and has regular communication with the intern 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 intern's experience.

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

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