Google Summer of Code 2024

From QEMU
Revision as of 19:30, 30 January 2024 by Stefanha (talk | contribs)

Introduction

QEMU is applying for Google Summer of Code 2024. 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 publish the list of accepted GSoC organizations at 18:00 UTC on February 21st. Applicants may get in touch with mentors before that date, but please don't invest too much time before accepted organizations are announced.

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. Submit your proposal

Upload your proposal PDF file to the Google Summer of Code website and notify your mentor(s) so they can give you feedback. You can make changes and upload the PDF again until the application deadline. Your proposal must include the following:

  • Project idea (title)
  • Your name and email address
  • Outline of your solution
    • Do some background research by looking at source code, browsing relevant specifications, etc in order to decide how to tackle the project. Discuss any questions with your mentor. This section will explain how your solution will work.
  • Project schedule
    • Create a week-by-week schedule of the coding period. Breaking down the project into tasks and estimate how many weeks they will take. The schedule can be adjusted during the summer so don't worry about getting everything right ahead of time.
  • Relevant experience (programming language knowledge, hobby projects, etc)
  • Are you available to work with no other commitments (jobs, university, vacation, etc) for the duration of your project? If not, please give details about the working hours and dates.

3. Contribution task

Once you have submitted your proposal PDF, let your mentor know and request a contribution task. The task will be a real bug or small feature that should not take more than 1 or 2 days to complete. This will allow you to demonstrate your skills in a realistic setting. Your mentor will provide you the details and help you with any questions.

Key Dates

From the timeline:

  • February 21 18:00 UTC - Organizations and project ideas announced
  • March 18 - April 2 18:00 UTC - Application period
  • April 21 - Contribution task deadline
  • May 1 18:00 UTC - Accepted applicants announced
  • May 27 - August 26 - 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.

GStreamer Backend for vhost-device-sound

Summary: Implement a GStreamer audio backend in rust-vmm's vhost-device-sound crate.

Project Description:

virtio-sound device emulation has recently been developed in the Rust vhost-device-sound crate. The crate currently contains audio backends for the ALSA and PipeWire sound APIs. The aim of this project is to build a new GStreamer audio backend.

Audio backends are written by implementing the AudioBackend trait. Refer to alsa.rs and pipewire.rs for examples of existing backends. The Stream and Buffer structs are used to transfer audio samples between the virtio-sound device and the sound API (e.g. GStreamer).

The backend should be implemented using the GStreamer Rust bindings. Mono and stereo playback and capture should be supported. The GStreamer pipelines for playback and capture will be hardcoded and only Linux needs to be supported.

Application Phase Tasks:

  • Familiarize yourself with the vhost-device-sound crate's AudioBackend trait and Stream and Buffer structs.
  • Familiarize yourself with the GStreamer Rust bindings.

Internship Tasks:

  • Write a skeleton for the GStreamer audio backend in the vhost-device-sound crate. Reviewing how the ALSA and PipeWire backends work is a helpful guide.
  • Implement playback functionality in the GStreamer audio backend for vhost-device-sound.
  • Implement capture functionality in the GStreamer audio backend for vhost-device-sound.
  • Implement automated tests with cargo test.
  • Test the implementation with QEMU, which can act as a vhost-user frontend.
  • As a stretch goal, contribute to the rust-vmm/vhost-device repo by fixing issues.

Links:

Details:

  • Project Size: 180 hrs
  • Skill level: intermediate
  • Language: Rust
  • Mentors: Dorinda Bassey <dbassey@redhat.com>, Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
  • Suggested by: Dorinda Bassey, Matias Ezequiel Vara Larsen

Add packed virtqueue to Shadow Virtqueue

Summary: Add the packed virtqueue format support to QEMU's Shadow Virtqueue.

To live migrate a guest with a passthrough device, QEMU needs a way to know which memory the device modifies so it is able to migrate it every time it is modified. Otherwise the migrated guest would resume with outdated memory contents after live migration.

This is especially hard with passthrough hardware devices, as transports like PCI impose a few security and performance challenges. As a method to overcome this for VIRTIO devices, QEMU can offer an emulated virtqueue to the device, called a Shadow Virtqueue (SVQ), instead of allowing the device to communicate directly with the guest. SVQ will then forward the writes to the guest, being the effective writer in the guest memory and knowing when a portion of it needs to be migrated again.

Compared with the original Split Virtqueue layout already supported by Shadow Virtqueues, the Packed Virtqueue layout is a more compact representation that uses less memory size and allows both devices and drivers to exchange the same amount of information with fewer memory operations.

The task is to complete the packed virtqueue support for SVQ, using the kernel VIRTIO ring driver as a reference. There is already a setup that can be used to test the changes.

Internship tasks:

  • Build the hands on blogs scenarios as development environment.
  • Understand (in a very high level) the virtqueue handling code, using the virtqueues blogs, the code from QEMU hw/virtio/virtio.c and the kernel drivers/virtio/virtio_ring.c.
  • Develop the basic code of the packet virtqueue in vhost-shadow-virtqueue.c, ignoring features like indirect.
  • Add event_idx code.
  • If there is bandwidth, add the corresponding device code to kernel's drivers/vhost/vringh, following the code of QEMU's device at hw/virtio/virtio.c.

Links:

Details:

  • Project size: 180 hrs
  • Skill level: Intermediate
  • Language: C
  • Mentors: Eugenio Perez Martin <eperezma@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>

vhost-user memory isolation

Summary: Add a new mode for vhost-user devices that does not expose guest RAM as shared memory.

vhost-user enables VIRTIO devices to be implemented as separate processes outside of QEMU. This allows device emulation code to be written in any programming language, sharing of device emulation code with other emulators besides QEMU, and complex device implementations that would not fit well into the QEMU process. vhost-user achieves good performance by directly accessing guest RAM through shared memory. Exposing guest RAM is not always desirable for security reasons and is sometimes not possible due to lack of host platform support. This project will add an alternative mode for vhost-user devices where guest RAM is not exposed.

Today, QEMU configures the guest in such a way that the vhost-user device is directly notified when I/O requests are ready for processing by the device. Similarly, when the vhost-user device completes I/O requests, it directly notifies the guest. The vhost-user device has full access to guest RAM via shared memory in order to transfer data buffers while processing I/O requests. This project will add a mode where QEMU intercepts I/O requests, copies data buffers between guest RAM and a vhost-user isolated memory area that the vhost-user device can access, and then forwards the notifications between the guest and the vhost-user device.

This approach of intercepting I/O requests is already being used in certain live migration scenarios and is called Shadow Virtqueue. The project will involve reusing the Shadow Virtqueue implementation and integrating it into the vhost-user code. It is important that existing vhost-user devices work with memory isolation and no vhost-user protocol changes are required.

You will gain experience with QEMU internals, VIRTIO, and vhost-user.

Internship tasks:

  • Add a bool "memory-isolation" qdev property to QEMU's vhost-user devices.
  • Modify hw/virtio/vhost-user.c to intercept and forward the vhost-user callfd and kickfd eventfds when memory isolation is enabled.
  • Manage an area of memory where I/O requests will be copied.
  • Integrate the existing Shadow Virtqueue (SVQ) code into hw/virtio/vhost-user.c so that vhost-user devices see the SVQ instead of the guest's virtqueue.
  • Extend tests/qtest/vhost-user-test.c to run with memory-isolation=on, proving that the feature works.

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate
  • Language: C
  • Mentor: Stefano Garzarella <sgarzare@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Eugenio Perez Martin <eperezma@redhat.com>, Hanna Czenczek <hreitz@redhat.com>

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.

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_2024&oldid=11637"