Google Summer of Code 2025

From QEMU

Introduction

QEMU is applying for Google Summer of Code 2025. 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 on Feb 27th.

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.

Tracing and logging in Rust

Expected outcome: Implement Rust APIs for tracing and logging.

The QEMU project is currently experimenting with using the Rust programming language to create new devices. As part of this, we have to write bindings to the C code that make it possible to use it from Rust safely. For example, QEMU needs to include Rust code to manage timers, interrupts and memory regions with safe and idiomatic Rust code.

QEMU integrates support for tracing using various backends---ranging from good old stdio to systemtap---thanks to a code generator that can produce tracing routines for the hundreds of tracepoints that QEMU supports; for more information see the links below. As part of this project, you will work on adding support for tracing and logging to Rust code.

The project spans multiple programming languages: the code generator is written in Python, the generated code will of course be Rust, and you will have to read some C to understand the subsystem.

Among similarly large open source C projects, QEMU is an early adopter for Rust! So you will also have a look at how the two languages can be integrated through the Meson build system.

Tasks:

  • implement bindings for QEMU's logging subsystem (logging is one of the tracing backends)
  • analyze the code generated by tracetool for C for the various tracing backends
  • try to implement by hand a few tracepoints in Rust
  • modify tracetool to generate the Rust code automatically

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate/advanced
  • Languages: Python, Rust, C
  • Mentor: Paolo Bonzini (OFTC: bonzini, Email: pbonzini@redhat.com)

Adding Kani proofs for Virtqueues in Rust-vmm

Expected outcome: Verify conformance of the virtqueue implementation in rust-vmm to the VirtIO specification.

In the rust-vmm project, devices rely on the virtqueue implementation provided by the `vm-virtio` crate. This implementation is based on the VirtIO specification, which defines the behavior and requirements for virtqueues. To ensure that the implementation meets these specifications, we have been relying on unit tests that check the output of the code given specific inputs.

However, writing unit tests can be incomplete, as it's challenging to cover all possible scenarios and edge cases. During this internship, we propose a more comprehensive approach: using Kani proofs to verify that the virtqueue implementation conforms to the VirtIO specification.

Kani allows us to write exhaustive checks for all possible values, going beyond what unit tests can achieve. By writing Kani proofs, we can confirm that our implementation meets the requirements of the VirtIO specification. If a proof passes, it provides strong evidence that the virtqueue implementation is correct and conformant.

Kani is an open-source tool and any issues like regarding performance can be reported on GitHub. For more information, the blog[1] contains several examples on how to use Kani in real codebases (including Firecracker). Also, there is a current effort for verifying the Rust Standard Library using Kani [2].

Tasks:

Links:

Details:

  • Project size: 175 or 350 hours, depending on how many proofs you wish to tackle
  • Skill level: intermediate
  • Language: Rust
  • Mentor: Matias Ezequiel Vara Larsen (mvaralar@redhat.com)

FUSE-over-io_uring exports

Expected outcome: Extend QEMU's FUSE export type with FUSE-over-io_uring support

FUSE-over-io_uring is a new high-performance interface for Filesystem in Userspace (FUSE) servers. The FUSE kernel code has added uring_cmd support so that FUSE servers can send and receive data directly over io_uring instead of reading/writing from/to the FUSE device. This reduces the number of system calls, as well as allowing for batching and polling, so that CPU overhead should be reduced.

QEMU's FUSE export type presents a file containing the contents of a disk image. This is a convenient way of using tools like fdisk(1) or dd(1) on a non-raw disk image file, like qcow2, that these tools would otherwise not be able to operate on. The current FUSE export implementation uses libfuse's FUSE device file descriptor handling APIs (fuse_session_fd(), fuse_session_receive_buf(), etc) to read(2)/write(2) in the traditional way.

Your task is to add FUSE-over-io_uring support as an alternative mode on systems where FUSE-over-io_uring is available.

Tasks:

  • Integrate FUSE-over-io_uring mode into the QEMU FUSE export
  • Add support for multiple in-flight requests
  • Benchmark with and without FUSE-over-io_uring using the fio(1) tool
  • Add support support multiple IOThreads

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate
  • Language: C
  • Mentors: Kevin Wolf (kwolf@redhat.com), Stefan Hajnoczi (stefanha@redhat.com)

Asynchronous request handling for virtiofsd

Expected outcome: Make virtiofsd’s request handling asynchronous, allowing single-threaded parallel request processing.

virtiofsd is a virtio-fs device implementation, i.e. grants VM guests access to host directories. In its current state, it processes guest requests one by one, which means operations of long duration will block processing of others that could be processed more quickly.

With asynchronous request processing, longer-lasting operations could continue in the background while other requests with lower latency are fetched and processed in parallel. This should improve performance especially for mixed workloads, i.e. one guest process executing longer-lasting filesystem operations, while another runs random small read requests on a single file.

Your task is to:

  • Get familiar with a Linux AIO interface, preferably io_uring
  • Have virtiofsd make use of that interface for its operations
  • Make the virtiofsd request loop process requests asynchronously, so requests can be fetched and processed while others are continuing in the background
  • Evaluate the resulting performance with different workloads

How you make the request loop asynchronous will largely be left to your discretion. You can use Rust async together with a runtime like tokio, some other runtime, or an entirely custom one; or keep the code synchronous, but allow deferring operations to the background, and when they complete, return the virtio descriptors to the guest then. That said, we assume that using async would provide the better long-term solution, as long as you’re comfortable to use/learn it.

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate
  • Language: Rust
  • Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione (gmaglione@redhat.com)

Implement LASI network card and/or NCR 710 SCSI controller device models

Expected outcome: Develop device emulations of the HP PA-RISC LASI network card and/or NCR 710 SCSI controller

QEMU can emulate a lot of physical machines. Beside widely used x86 machines as used with KVM, this includes historic machines based on PowerPC, Alpha or HP PA-RISC CPUs too. To emulate additional historic machine models, device models that emulate specific hardware like network or SCSI cards need to be developed.

This project is about developing such a device model for the historic HP PA-RISC architecture. Based on the knowledge and interest of the applicant, here are two non-exclusive options:

1. LASI network card. This is basically an Intel 82596 network chip, which was integrated into another ASIC in the HP 700 series. That chip was used in SUN machines as well, and the full Linux driver source code for the various machines is available. A QEMU device model exists (see here and here), but it's not fully functional yet. Datasheets for this chip exists too. This project is about debugging and analyzing existing code, including development of missing code.

2. First-generation NCR 710 SCSI controller. Really old machines used a NCR 710 SCSI controller, for which currently no QEMU device model exists. QEMU has a LSI53C895A device model, which partly even allows emulating a LSI53C810, but those chips are "too new" and as such are not accepted and supported on old operating systems (e.g. HP-UX9). The WinUAE project seem to have modified the existing QEMU device model to emulate a NCR 710 to support the Amiga. The goal of this project is to develop a nice & clean NCR 710 device model that can be merged into QEMU.

Links:

Details:

  • Project size: 350 hours
  • Skill level: advanced
  • Language: C
  • Mentor: Helge Deller (deller@gmx.de)

vhost-user devices in Rust on macOS and *BSD

Expected outcome: Extend rust-vmm crates to support vhost-user devices running on POSIX system like macOS and *BSD.

VIRTIO devices can be emulated in an external process to QEMU thanks to the vhost-user protocol, which allows QEMU to offload the entire emulation to a daemon. This is done through an AF_UNIX socket used as a control path between the frontend (i.e. QEMU) and the backend (i.e. the vhost-user daemon). QEMU will share guest memory with the daemon, provide all the information for data path setup, and notification mechanisms.

Moving the emulation of VIRTIO devices to a separate process from QEMU offers significant advantages, primarily in terms of safety, if a device crashes, we can restart it without affecting QEMU. Additionally, this approach simplifies updating device implementations, allows development in other languages (such as Rust as we do in the rust-vmm community), and enhances isolation through seccomp, cgroups, and similar mechanisms.

The rust-vmm community already provides several crates (e.g. vhost, vhost-user-backend, etc.) to implement a vhost-user backend in an external daemon. For example, these crates are used by virtiofsd (virtio-fs vhost-user device) but also by all vhost-user devices maintained by the rust-vmm community in the rust-vmm/vhost-device workspace. These crates work great on Linux, but unfortunately they use some Linux-specific system calls such as epoll(7) and eventfd(2) that make them impossible to use on other POSIX systems.

The goal of this project is to make sure that we can use rust-vmm's vhost and vhost-user-backend crates on other POSIX systems besides Linux. If time permits, we could also fix up simple devices such as vhost-device-console or vhost-device-vsock to run on any POSIX systems.

Tasks:

  • Run QEMU with a vhost-user device on macOS or FreeBSD/OpenBSD as covered in the FOSDEM 2025 talk
  • Analyze rust-vmm crates (vmm-sys-util, vhost, vhost-user-backend) to understand which components are Linux-specific
  • Replace epoll(7) with alternatives such as https://github.com/smol-rs/polling
  • Automatic fallback to pipe()/pipe2() if eventfd(2) is not available as QEMU already does
  • Handle any other cases discovered during the analysis
  • Adapt a simple device such as vhost-device-console or vhost-device-vsock to test that everything works on macOS or FreeBSD/OpenBSD

Links:

Details:

  • Project size: 350 hours
  • Skill level: intermediate
  • Language: Rust
  • Mentors: Stefano Garzarella <sgarzare@redhat.com>, German Maglione <gmaglione@redhat.com>

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 27 18:00 UTC - Organizations and project ideas announced
  • March 24 - April 8 18:00 UTC - Application period
  • April 15 - Contribution task deadline
  • May 8 18:00 UTC - Accepted applicants announced
  • June 2 - September 1 - 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:

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_2025&oldid=12133"