Call for GSoC internship project ideas

Call for GSoC internship project ideas

[Stefan Hajnoczi]

Dear QEMU and KVM communities,
QEMU will apply for the Google Summer of Code internship
program again this year. Regular contributors can submit project
ideas that they'd like to mentor by replying to this email by
February 7th.

About Google Summer of Code
-----------------------------------------
GSoC (https://summerofcode.withgoogle.com/) offers paid open
source remote work internships to eligible people wishing to participate
in open source development. QEMU has been doing internship for
many years. Our mentors have enjoyed helping talented interns make
their first open source contributions and some former interns continue
to participate today.

Who can mentor
----------------------
Regular contributors to QEMU and KVM can participate as mentors.
Mentorship involves about 5 hours of time commitment per week to
communicate with the intern, review their patches, etc. Time is also
required during the intern selection phase to communicate with
applicants. Being a mentor is an opportunity to help someone get
started in open source development, will give you experience with
managing a project in a low-stakes environment, and a chance to
explore interesting technical ideas that you may not have time to
develop yourself.

How to propose your idea
------------------------------
Reply to this email with the following project idea template filled in:

=== TITLE ===

'''Summary:''' Short description of the project

Detailed description of the project that explains the general idea,
including a list of high-level tasks that will be completed by the
project, and provides enough background for someone unfamiliar with
the code base to research the idea. Typically 2 or 3 paragraphs.

'''Links:'''
* Links to mailing lists threads, git repos, or web sites

'''Details:'''
* Skill level: beginner or intermediate or advanced
* Language: C/Python/Rust/etc

More information
----------------------
You can find out about the process we follow here:
Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf

The QEMU wiki page for GSoC 2024 is now available:
https://wiki.qemu.org/Google_Summer_of_Code_2025

What about Outreachy?
-------------------------------
We have struggled to find sponsors for the Outreachy internship
program (https://www.outreachy.org/) in recent years. If you or your
organization would like to sponsor an Outreachy internship, please get
in touch.

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Stefano Garzarella]

+Cc rust-vmm ML, since in past years we have used QEMU as an umbrella
project for rust-vmm ideas for GSoC.

Thanks,
Stefano

On Tue, 28 Jan 2025 at 17:17, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> February 7th.
>
> About Google Summer of Code
> -----------------------------------------
> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> source remote work internships to eligible people wishing to participate
> in open source development. QEMU has been doing internship for
> many years. Our mentors have enjoyed helping talented interns make
> their first open source contributions and some former interns continue
> to participate today.
>
> Who can mentor
> ----------------------
> Regular contributors to QEMU and KVM can participate as mentors.
> Mentorship involves about 5 hours of time commitment per week to
> communicate with the intern, review their patches, etc. Time is also
> required during the intern selection phase to communicate with
> applicants. Being a mentor is an opportunity to help someone get
> started in open source development, will give you experience with
> managing a project in a low-stakes environment, and a chance to
> explore interesting technical ideas that you may not have time to
> develop yourself.
>
> How to propose your idea
> ------------------------------
> Reply to this email with the following project idea template filled in:
>
> === TITLE ===
>
> '''Summary:''' Short description of the project
>
> Detailed description of the project that explains the general idea,
> including a list of high-level tasks that will be completed by the
> project, and provides enough background for someone unfamiliar with
> the code base to research the idea. Typically 2 or 3 paragraphs.
>
> '''Links:'''
> * Links to mailing lists threads, git repos, or web sites
>
> '''Details:'''
> * Skill level: beginner or intermediate or advanced
> * Language: C/Python/Rust/etc
>
> More information
> ----------------------
> You can find out about the process we follow here:
> Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
> Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
>
> The QEMU wiki page for GSoC 2024 is now available:
> https://wiki.qemu.org/Google_Summer_of_Code_2025
>
> What about Outreachy?
> -------------------------------
> We have struggled to find sponsors for the Outreachy internship
> program (https://www.outreachy.org/) in recent years. If you or your
> organization would like to sponsor an Outreachy internship, please get
> in touch.
>
> Thanks,
> Stefan
>

RE: Call for GSoC internship project ideas

[Jamin Lin]

+ Troy

************* Email Confidentiality Notice ********************
免責聲明:
本信件(或其附件)可能包含機密資訊，並受法律保護。如 台端非指定之收件者，請以電子郵件通知本電子郵件之發送者, 並請立即刪除本電子郵件及其附件和銷毀所有複印件。謝謝您的合作!

DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you. 

> -----Original Message-----
> From: Stefano Garzarella <sgarzare@redhat.com>
> Sent: Thursday, January 30, 2025 1:44 AM
> To: Rust-VMM Mailing List <rust-vmm@lists.opendev.org>
> Cc: Stefan Hajnoczi <stefanha@gmail.com>; qemu-devel
> <qemu-devel@nongnu.org>; kvm <kvm@vger.kernel.org>; Richard Henderson
> <richard.henderson@linaro.org>; Philippe Mathieu-Daudé
> <philmd@linaro.org>; Peter Maydell <peter.maydell@linaro.org>; Paolo
> Bonzini <pbonzini@redhat.com>; Thomas Huth <thuth@redhat.com>; Daniel P.
> Berrange <berrange@redhat.com>; Pierrick Bouvier
> <pierrick.bouvier@linaro.org>; Alex Bennee <alex.bennee@linaro.org>;
> Akihiko Odaki <akihiko.odaki@gmail.com>; Zhao Liu <zhao1.liu@intel.com>;
> Bibo Mao <maobibo@loongson.cn>; Jamin Lin <jamin_lin@aspeedtech.com>;
> Cédric Le Goater <clg@redhat.com>; Fabiano Rosas <farosas@suse.de>;
> Palmer Dabbelt <palmer@dabbelt.com>; Eugenio Pérez
> <eperezma@redhat.com>; Hanna Reitz <hreitz@redhat.com>
> Subject: Re: Call for GSoC internship project ideas
> 
> +Cc rust-vmm ML, since in past years we have used QEMU as an umbrella
> project for rust-vmm ideas for GSoC.
> 
> Thanks,
> Stefano
> 
> On Tue, 28 Jan 2025 at 17:17, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship program again
> > this year. Regular contributors can submit project ideas that they'd
> > like to mentor by replying to this email by February 7th.
> >
> > About Google Summer of Code
> > -----------------------------------------
> > GSoC (https://summerofcode.withgoogle.com/) offers paid open source
> > remote work internships to eligible people wishing to participate in
> > open source development. QEMU has been doing internship for many
> > years. Our mentors have enjoyed helping talented interns make their
> > first open source contributions and some former interns continue to
> > participate today.
> >
> > Who can mentor
> > ----------------------
> > Regular contributors to QEMU and KVM can participate as mentors.
> > Mentorship involves about 5 hours of time commitment per week to
> > communicate with the intern, review their patches, etc. Time is also
> > required during the intern selection phase to communicate with
> > applicants. Being a mentor is an opportunity to help someone get
> > started in open source development, will give you experience with
> > managing a project in a low-stakes environment, and a chance to
> > explore interesting technical ideas that you may not have time to
> > develop yourself.
> >
> > How to propose your idea
> > ------------------------------
> > Reply to this email with the following project idea template filled in:
> >
> > === TITLE ===
> >
> > '''Summary:''' Short description of the project
> >
> > Detailed description of the project that explains the general idea,
> > including a list of high-level tasks that will be completed by the
> > project, and provides enough background for someone unfamiliar with
> > the code base to research the idea. Typically 2 or 3 paragraphs.
> >
> > '''Links:'''
> > * Links to mailing lists threads, git repos, or web sites
> >
> > '''Details:'''
> > * Skill level: beginner or intermediate or advanced
> > * Language: C/Python/Rust/etc
> >
> > More information
> > ----------------------
> > You can find out about the process we follow here:
> > Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
> > Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> >
> > The QEMU wiki page for GSoC 2024 is now available:
> > https://wiki.qemu.org/Google_Summer_of_Code_2025
> >
> > What about Outreachy?
> > -------------------------------
> > We have struggled to find sponsors for the Outreachy internship
> > program (https://www.outreachy.org/) in recent years. If you or your
> > organization would like to sponsor an Outreachy internship, please get
> > in touch.
> >
> > Thanks,
> > Stefan
> >

Re: Call for GSoC internship project ideas

[Stefano Garzarella]

Hi Stefan,
Sorry for the delay, I attach a proposal!

On Wed, 29 Jan 2025 at 18:44, Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> +Cc rust-vmm ML, since in past years we have used QEMU as an umbrella
> project for rust-vmm ideas for GSoC.
>
> Thanks,
> Stefano
>
> On Tue, 28 Jan 2025 at 17:17, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship
> > program again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email by
> > February 7th.
> >
> > About Google Summer of Code
> > -----------------------------------------
> > GSoC (https://summerofcode.withgoogle.com/) offers paid open
> > source remote work internships to eligible people wishing to participate
> > in open source development. QEMU has been doing internship for
> > many years. Our mentors have enjoyed helping talented interns make
> > their first open source contributions and some former interns continue
> > to participate today.
> >
> > Who can mentor
> > ----------------------
> > Regular contributors to QEMU and KVM can participate as mentors.
> > Mentorship involves about 5 hours of time commitment per week to
> > communicate with the intern, review their patches, etc. Time is also
> > required during the intern selection phase to communicate with
> > applicants. Being a mentor is an opportunity to help someone get
> > started in open source development, will give you experience with
> > managing a project in a low-stakes environment, and a chance to
> > explore interesting technical ideas that you may not have time to
> > develop yourself.
> >
> > How to propose your idea
> > ------------------------------
> > Reply to this email with the following project idea template filled in:


=== vhost-user devices in Rust on macOS and *BSD ===

'''Summary:''' 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:'''
* Becoming familiar with QEMU and vhost-user devices
* 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:'''
* FOSDEM 2025 talk: [https://fosdem.org/2025/schedule/event/fosdem-2025-5100-can-qemu-and-vhost-user-devices-be-used-on-macos-and-bsd-/ Can QEMU and vhost-user devices be used on macOS and *BSD?]
* [https://qemu-project.gitlab.io/qemu/interop/vhost-user.html vhost-user spacification]
* [https://patchew.org/QEMU/20240618100043.144657-1-sgarzare@redhat.com/ QEMU series to support vhost-user on any POSIX]
* [https://gitlab.com/sgarzarella/qemu/-/tree/macos-vhost-user sgarzare's tree where to find some missing QEMU patches]
* [https://github.com/rust-vmm/vhost rust-vmm vhost & vhost-user-backend crates]
* [https://github.com/rust-vmm/vmm-sys-util rust-vmm vmm-sys-util crate]
* [https://github.com/rust-vmm/vhost-device rust-vmm vhost-device workspace]
* [https://gitlab.com/virtio-fs/virtiofsd virtio-fs vhost-user device]
* [https://github.com/rust-vmm/vhost/issues/110 Mac build support #110 - rust-vmm/vhost]
* [https://gitlab.com/virtio-fs/virtiofsd/-/issues/169 Add macOS support #169 - virtio-fs/virtiofsd]

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


Thanks,
Stefano

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Mon, Feb 10, 2025 at 9:55 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
> === vhost-user devices in Rust on macOS and *BSD ===
>
> '''Summary:''' Extend rust-vmm crates to support vhost-user devices
> running on POSIX system like macOS and *BSD

Thanks, I have added it to the wiki:
https://wiki.qemu.org/Google_Summer_of_Code_2025#vhost-user_devices_in_Rust_on_macOS_and_*BSD

Stefan

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

On Tue, Jan 28, 2025 at 11:16:43AM -0500, Stefan Hajnoczi wrote:
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> February 7th.
> 
> About Google Summer of Code
> -----------------------------------------
> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> source remote work internships to eligible people wishing to participate
> in open source development. QEMU has been doing internship for
> many years. Our mentors have enjoyed helping talented interns make
> their first open source contributions and some former interns continue
> to participate today.
> 
> Who can mentor
> ----------------------
> Regular contributors to QEMU and KVM can participate as mentors.
> Mentorship involves about 5 hours of time commitment per week to
> communicate with the intern, review their patches, etc. Time is also
> required during the intern selection phase to communicate with
> applicants. Being a mentor is an opportunity to help someone get
> started in open source development, will give you experience with
> managing a project in a low-stakes environment, and a chance to
> explore interesting technical ideas that you may not have time to
> develop yourself.
> 
> How to propose your idea
> ------------------------------
> Reply to this email with the following project idea template filled in:
> 
> === TITLE ===
> 
> '''Summary:''' Short description of the project
> 
> Detailed description of the project that explains the general idea,
> including a list of high-level tasks that will be completed by the
> project, and provides enough background for someone unfamiliar with
> the code base to research the idea. Typically 2 or 3 paragraphs.
> 
> '''Links:'''
> * Links to mailing lists threads, git repos, or web sites
> 
> '''Details:'''
> * Skill level: beginner or intermediate or advanced
> * Language: C/Python/Rust/etc
> 
> More information
> ----------------------
> You can find out about the process we follow here:
> Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
> Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> 
> The QEMU wiki page for GSoC 2024 is now available:
> https://wiki.qemu.org/Google_Summer_of_Code_2025
> 
> What about Outreachy?
> -------------------------------
> We have struggled to find sponsors for the Outreachy internship
> program (https://www.outreachy.org/) in recent years. If you or your
> organization would like to sponsor an Outreachy internship, please get
> in touch.
> 
> Thanks,
> Stefan

=== Adding Kani proofs for Virtqueues in Rust-vmm ===

'''Summary:''' 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.

During the internship, we propose the following tasks:
- Get familiar with Kani proofs written for Firecraker
- Finish current PR that adds a proof for the notification suppression
  mechanism (see [2])
- Port add_used() proof (see [5])
- Port verify_prepare_kick() proof (see [6])

'''Links:'''
  * [1] Kani source code - https://github.com/model-checking/kani/
  * [2] Notification suppression mechanism PR -
    https://github.com/rust-vmm/vm-virtio/pull/324
  * [3] LPC Talk about how we may check conformance in the VirtIO
    specification - https://www.youtube.com/watch?v=w7BAR228344
  * [4] FOSDEM'25 talk current effort to use Kani -
    https://fosdem.org/2025/schedule/event/fosdem-2025-5930-hunting-virtio-specification-violations/
  * [5] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L1006
  * [6] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L966
 
'''Details:'''
  * Skill level: intermediate
  * Language: Rust 

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Thu, Feb 6, 2025 at 4:34 AM Matias Ezequiel Vara Larsen
<mvaralar@redhat.com> wrote:
> === Adding Kani proofs for Virtqueues in Rust-vmm ===
>
> '''Summary:''' 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.
>
> During the internship, we propose the following tasks:
> - Get familiar with Kani proofs written for Firecraker
> - Finish current PR that adds a proof for the notification suppression
>   mechanism (see [2])
> - Port add_used() proof (see [5])
> - Port verify_prepare_kick() proof (see [6])

add_used(), verify_prepare_kick(), and notification suppression are
explicitly named. Firecracker's queue.rs has proofs for a number of
other proofs as well. Would it be possible to work on them if there is
time remaining, or is there a reason why only the proofs you mentioned
can be ported?

I'm asking because a 12-week internship is likely to leave enough time
to tackle more than 3 proofs.

Stefan

>
> '''Links:'''
>   * [1] Kani source code - https://github.com/model-checking/kani/
>   * [2] Notification suppression mechanism PR -
>     https://github.com/rust-vmm/vm-virtio/pull/324
>   * [3] LPC Talk about how we may check conformance in the VirtIO
>     specification - https://www.youtube.com/watch?v=w7BAR228344
>   * [4] FOSDEM'25 talk current effort to use Kani -
>     https://fosdem.org/2025/schedule/event/fosdem-2025-5930-hunting-virtio-specification-violations/
>   * [5] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L1006
>   * [6] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L966
>
> '''Details:'''
>   * Skill level: intermediate
>   * Language: Rust
>

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

On Thu, Feb 06, 2025 at 10:02:43AM -0500, Stefan Hajnoczi wrote:
> On Thu, Feb 6, 2025 at 4:34 AM Matias Ezequiel Vara Larsen
> <mvaralar@redhat.com> wrote:
> > === Adding Kani proofs for Virtqueues in Rust-vmm ===
> >
> > '''Summary:''' 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.
> >
> > During the internship, we propose the following tasks:
> > - Get familiar with Kani proofs written for Firecraker
> > - Finish current PR that adds a proof for the notification suppression
> >   mechanism (see [2])
> > - Port add_used() proof (see [5])
> > - Port verify_prepare_kick() proof (see [6])
> 
> add_used(), verify_prepare_kick(), and notification suppression are
> explicitly named. Firecracker's queue.rs has proofs for a number of
> other proofs as well. Would it be possible to work on them if there is
> time remaining, or is there a reason why only the proofs you mentioned
> can be ported?
> 

I though that those three proofs were the more interesting. I think we
can cover all the proofs in queue.rs during the internship.

Matias

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

I have added your project idea to the wiki. Please make further
changes directly on the wiki.

https://wiki.qemu.org/Google_Summer_of_Code_2025#Adding_Kani_proofs_for_Virtqueues_in_Rust-vmm

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

On Thu, Feb 06, 2025 at 10:10:54AM -0500, Stefan Hajnoczi wrote:
> I have added your project idea to the wiki. Please make further
> changes directly on the wiki.
> 
> https://wiki.qemu.org/Google_Summer_of_Code_2025#Adding_Kani_proofs_for_Virtqueues_in_Rust-vmm
> 
> Thanks,
> Stefan
> 

Thanks,

Matias.

Re: Call for GSoC internship project ideas

[Hanna Czenczek]

On 28.01.25 17:16, Stefan Hajnoczi wrote:
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> February 7th.
>
> About Google Summer of Code
> -----------------------------------------
> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> source remote work internships to eligible people wishing to participate
> in open source development. QEMU has been doing internship for
> many years. Our mentors have enjoyed helping talented interns make
> their first open source contributions and some former interns continue
> to participate today.
>
> Who can mentor
> ----------------------
> Regular contributors to QEMU and KVM can participate as mentors.
> Mentorship involves about 5 hours of time commitment per week to
> communicate with the intern, review their patches, etc. Time is also
> required during the intern selection phase to communicate with
> applicants. Being a mentor is an opportunity to help someone get
> started in open source development, will give you experience with
> managing a project in a low-stakes environment, and a chance to
> explore interesting technical ideas that you may not have time to
> develop yourself.
>
> How to propose your idea
> ------------------------------
> Reply to this email with the following project idea template filled in:
>
> === TITLE ===
>
> '''Summary:''' Short description of the project
>
> Detailed description of the project that explains the general idea,
> including a list of high-level tasks that will be completed by the
> project, and provides enough background for someone unfamiliar with
> the code base to research the idea. Typically 2 or 3 paragraphs.
>
> '''Links:'''
> * Links to mailing lists threads, git repos, or web sites
>
> '''Details:'''
> * Skill level: beginner or intermediate or advanced
> * Language: C/Python/Rust/etc

=== Asynchronous request handling for virtiofsd ===

'''Summary:''' 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

'''Links:'''
* virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
* virtiofsd’s filesystem operations: 
https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
* virtiofsd’s request processing loop: 
https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244

'''Details:'''
* Skill level: intermediate
* Language: Rust
* Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione 
(gmaglione@redhat.com)

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@redhat.com> wrote:
>
> On 28.01.25 17:16, Stefan Hajnoczi wrote:
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship
> > program again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email by
> > February 7th.
> >
> > About Google Summer of Code
> > -----------------------------------------
> > GSoC (https://summerofcode.withgoogle.com/) offers paid open
> > source remote work internships to eligible people wishing to participate
> > in open source development. QEMU has been doing internship for
> > many years. Our mentors have enjoyed helping talented interns make
> > their first open source contributions and some former interns continue
> > to participate today.
> >
> > Who can mentor
> > ----------------------
> > Regular contributors to QEMU and KVM can participate as mentors.
> > Mentorship involves about 5 hours of time commitment per week to
> > communicate with the intern, review their patches, etc. Time is also
> > required during the intern selection phase to communicate with
> > applicants. Being a mentor is an opportunity to help someone get
> > started in open source development, will give you experience with
> > managing a project in a low-stakes environment, and a chance to
> > explore interesting technical ideas that you may not have time to
> > develop yourself.
> >
> > How to propose your idea
> > ------------------------------
> > Reply to this email with the following project idea template filled in:
> >
> > === TITLE ===
> >
> > '''Summary:''' Short description of the project
> >
> > Detailed description of the project that explains the general idea,
> > including a list of high-level tasks that will be completed by the
> > project, and provides enough background for someone unfamiliar with
> > the code base to research the idea. Typically 2 or 3 paragraphs.
> >
> > '''Links:'''
> > * Links to mailing lists threads, git repos, or web sites
> >
> > '''Details:'''
> > * Skill level: beginner or intermediate or advanced
> > * Language: C/Python/Rust/etc
>
> === Asynchronous request handling for virtiofsd ===
>
> '''Summary:''' 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
>
> '''Links:'''
> * virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
> * virtiofsd’s filesystem operations:
> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
> * virtiofsd’s request processing loop:
> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244
>
> '''Details:'''
> * Skill level: intermediate
> * Language: Rust
> * Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione
> (gmaglione@redhat.com)

Thanks, I have added your project idea to the list:
https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd

Do you want to give any guidance on which crate to use for
asynchronous I/O? Do you want async Rust (e.g. tokio) or not?

Stefan

Re: Call for GSoC internship project ideas

[Hanna Czenczek]

On 07.02.25 14:41, Stefan Hajnoczi wrote:
> On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@redhat.com> wrote:
>> On 28.01.25 17:16, Stefan Hajnoczi wrote:
>>> Dear QEMU and KVM communities,
>>> QEMU will apply for the Google Summer of Code internship
>>> program again this year. Regular contributors can submit project
>>> ideas that they'd like to mentor by replying to this email by
>>> February 7th.
>>>
>>> About Google Summer of Code
>>> -----------------------------------------
>>> GSoC (https://summerofcode.withgoogle.com/) offers paid open
>>> source remote work internships to eligible people wishing to participate
>>> in open source development. QEMU has been doing internship for
>>> many years. Our mentors have enjoyed helping talented interns make
>>> their first open source contributions and some former interns continue
>>> to participate today.
>>>
>>> Who can mentor
>>> ----------------------
>>> Regular contributors to QEMU and KVM can participate as mentors.
>>> Mentorship involves about 5 hours of time commitment per week to
>>> communicate with the intern, review their patches, etc. Time is also
>>> required during the intern selection phase to communicate with
>>> applicants. Being a mentor is an opportunity to help someone get
>>> started in open source development, will give you experience with
>>> managing a project in a low-stakes environment, and a chance to
>>> explore interesting technical ideas that you may not have time to
>>> develop yourself.
>>>
>>> How to propose your idea
>>> ------------------------------
>>> Reply to this email with the following project idea template filled in:
>>>
>>> === TITLE ===
>>>
>>> '''Summary:''' Short description of the project
>>>
>>> Detailed description of the project that explains the general idea,
>>> including a list of high-level tasks that will be completed by the
>>> project, and provides enough background for someone unfamiliar with
>>> the code base to research the idea. Typically 2 or 3 paragraphs.
>>>
>>> '''Links:'''
>>> * Links to mailing lists threads, git repos, or web sites
>>>
>>> '''Details:'''
>>> * Skill level: beginner or intermediate or advanced
>>> * Language: C/Python/Rust/etc
>> === Asynchronous request handling for virtiofsd ===
>>
>> '''Summary:''' 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
>>
>> '''Links:'''
>> * virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
>> * virtiofsd’s filesystem operations:
>> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
>> * virtiofsd’s request processing loop:
>> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244
>>
>> '''Details:'''
>> * Skill level: intermediate
>> * Language: Rust
>> * Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione
>> (gmaglione@redhat.com)
> Thanks, I have added your project idea to the list:
> https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd

Thanks!

> Do you want to give any guidance on which crate to use for
> asynchronous I/O? Do you want async Rust (e.g. tokio) or not?

That would depend entirely on the student.  I’m open for async Rust 
(tokio or even homegrown), but they could also decide they’d rather do 
it in some different manner (e.g. with callbacks that would return 
descriptors to the guest).  I’ll add that info, if that’s OK.

Hanna

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Fri, Feb 7, 2025 at 8:48 AM Hanna Czenczek <hreitz@redhat.com> wrote:
>
> On 07.02.25 14:41, Stefan Hajnoczi wrote:
> > On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@redhat.com> wrote:
> >> On 28.01.25 17:16, Stefan Hajnoczi wrote:
> >>> Dear QEMU and KVM communities,
> >>> QEMU will apply for the Google Summer of Code internship
> >>> program again this year. Regular contributors can submit project
> >>> ideas that they'd like to mentor by replying to this email by
> >>> February 7th.
> >>>
> >>> About Google Summer of Code
> >>> -----------------------------------------
> >>> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> >>> source remote work internships to eligible people wishing to participate
> >>> in open source development. QEMU has been doing internship for
> >>> many years. Our mentors have enjoyed helping talented interns make
> >>> their first open source contributions and some former interns continue
> >>> to participate today.
> >>>
> >>> Who can mentor
> >>> ----------------------
> >>> Regular contributors to QEMU and KVM can participate as mentors.
> >>> Mentorship involves about 5 hours of time commitment per week to
> >>> communicate with the intern, review their patches, etc. Time is also
> >>> required during the intern selection phase to communicate with
> >>> applicants. Being a mentor is an opportunity to help someone get
> >>> started in open source development, will give you experience with
> >>> managing a project in a low-stakes environment, and a chance to
> >>> explore interesting technical ideas that you may not have time to
> >>> develop yourself.
> >>>
> >>> How to propose your idea
> >>> ------------------------------
> >>> Reply to this email with the following project idea template filled in:
> >>>
> >>> === TITLE ===
> >>>
> >>> '''Summary:''' Short description of the project
> >>>
> >>> Detailed description of the project that explains the general idea,
> >>> including a list of high-level tasks that will be completed by the
> >>> project, and provides enough background for someone unfamiliar with
> >>> the code base to research the idea. Typically 2 or 3 paragraphs.
> >>>
> >>> '''Links:'''
> >>> * Links to mailing lists threads, git repos, or web sites
> >>>
> >>> '''Details:'''
> >>> * Skill level: beginner or intermediate or advanced
> >>> * Language: C/Python/Rust/etc
> >> === Asynchronous request handling for virtiofsd ===
> >>
> >> '''Summary:''' 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
> >>
> >> '''Links:'''
> >> * virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
> >> * virtiofsd’s filesystem operations:
> >> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
> >> * virtiofsd’s request processing loop:
> >> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244
> >>
> >> '''Details:'''
> >> * Skill level: intermediate
> >> * Language: Rust
> >> * Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione
> >> (gmaglione@redhat.com)
> > Thanks, I have added your project idea to the list:
> > https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd
>
> Thanks!
>
> > Do you want to give any guidance on which crate to use for
> > asynchronous I/O? Do you want async Rust (e.g. tokio) or not?
>
> That would depend entirely on the student.  I’m open for async Rust
> (tokio or even homegrown), but they could also decide they’d rather do
> it in some different manner (e.g. with callbacks that would return
> descriptors to the guest).  I’ll add that info, if that’s OK.

Sounds good.

Stefan

Call for GSoC internship project ideas

[Stefan Hajnoczi]

Dear QEMU and KVM communities,
QEMU will apply for the Google Summer of Code internship
program again this year. Regular contributors can submit project
ideas that they'd like to mentor by replying to this email by
January 30th.

About Google Summer of Code
-----------------------------------------
GSoC (https://summerofcode.withgoogle.com/) offers paid open
source remote work internships to eligible people wishing to participate
in open source development. QEMU has been doing internship for
many years. Our mentors have enjoyed helping talented interns make
their first open source contributions and some former interns continue
to participate today.

Who can mentor
----------------------
Regular contributors to QEMU and KVM can participate as mentors.
Mentorship involves about 5 hours of time commitment per week to
communicate with the intern, review their patches, etc. Time is also
required during the intern selection phase to communicate with
applicants. Being a mentor is an opportunity to help someone get
started in open source development, will give you experience with
managing a project in a low-stakes environment, and a chance to
explore interesting technical ideas that you may not have time to
develop yourself.

How to propose your idea
------------------------------
Reply to this email with the following project idea template filled in:

=== TITLE ===

'''Summary:''' Short description of the project

Detailed description of the project that explains the general idea,
including a list of high-level tasks that will be completed by the
project, and provides enough background for someone unfamiliar with
the code base to research the idea. Typically 2 or 3 paragraphs.

'''Links:'''
* Links to mailing lists threads, git repos, or web sites

'''Details:'''
* Skill level: beginner or intermediate or advanced
* Language: C/Python/Rust/etc

More information
----------------------
You can find out about the process we follow here:
Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf

The QEMU wiki page for GSoC 2026 is now available:
https://wiki.qemu.org/Google_Summer_of_Code_2026

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Peter Xu]

On Mon, Jan 05, 2026 at 04:47:22PM -0500, Stefan Hajnoczi wrote:
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> January 30th.

There's one idea from migration side that should be self-contained, please
evaluate if this suites for the application.

I copied Marco who might be interested on such project too at least from an
user perspective on fuzzing [1].

[1] https://lore.kernel.org/all/193e5a-681dfa80-3af-701c0f80@227192887/

Thanks,

=== Fast Snapshot Load ===

'''Summary:''' Fast loadvm process based on postcopy approach

We have two common ways to load snapshots: (1) QMP "snapshot-load", or QMP
"migrate_incoming" with a "file:" URI. The idea to be discussed here should
apply to either form of loadvm, however here we will focus on "file:"
migration only, because it should be the modern and suggested way of using
snapshots nowadays.

Load snapshot currently requires all VM data (RAM states and the rest
device states) to be loaded into the QEMU instance before VM starts.

It is not required, though, to load guest memory to start the VM. For
example, in a postcopy live migration process, QEMU uses userfaultfd to
allow VM run without all of the guest memory migrated. A similar technique
can also be used in a loadvm process to make loadvm very fast, starting the
VM almost immediately right after the loadvm command.

The idea is simple: we can start the VM right after loading device states
(but without loading the guest memory), then QEMU can start the VM. In the
background, the loadvm process should keep loading all the VM data in an
atomically way. Meanwhile, the vCPUs may from time to time access a missing
guest page. QEMU needs to trap these accesses with userfaultfd, and resolve
the page faults.

After loading all the RAM state, the whole loadvm procedure is completed.

This feature needs to depend on mapped-ram feature, which allows offsetting
into the snapshots to find whatever page being asked by the guest vCPUs at
any point in time.

This feature may not be very help in VM suspend / resume use cases, because
in those cases the VM was down previously, normally it's fine waiting for
the VM to be fully loaded. However, it might be useful in some other cases
(like, frequently loading snapshots).

'''Links:'''
* https://wiki.qemu.org/ToDo/LiveMigration#Fast_load_snapshot

'''Details:'''
* Skill level: advanced
* Language: C
* Mentor: Peter Xu <peterx@redhat.com>, peterx (on #qemu IRC)

-- 
Peter Xu

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Tue, Jan 13, 2026 at 10:30 AM Peter Xu <peterx@redhat.com> wrote:
>
> On Mon, Jan 05, 2026 at 04:47:22PM -0500, Stefan Hajnoczi wrote:
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship
> > program again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email by
> > January 30th.
>
> There's one idea from migration side that should be self-contained, please
> evaluate if this suites for the application.
>
> I copied Marco who might be interested on such project too at least from an
> user perspective on fuzzing [1].
>
> [1] https://lore.kernel.org/all/193e5a-681dfa80-3af-701c0f80@227192887/
>
> Thanks,

I have edited the project description to make it easier for newcomers
to understand and added a link to mapped-ram.rst:
https://wiki.qemu.org/Google_Summer_of_Code_2026#Fast_Snapshot_Load

Feel free to edit the project idea on the wiki.

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Peter Xu]

On Tue, Jan 13, 2026 at 11:16:27AM -0500, Stefan Hajnoczi wrote:
> On Tue, Jan 13, 2026 at 10:30 AM Peter Xu <peterx@redhat.com> wrote:
> >
> > On Mon, Jan 05, 2026 at 04:47:22PM -0500, Stefan Hajnoczi wrote:
> > > Dear QEMU and KVM communities,
> > > QEMU will apply for the Google Summer of Code internship
> > > program again this year. Regular contributors can submit project
> > > ideas that they'd like to mentor by replying to this email by
> > > January 30th.
> >
> > There's one idea from migration side that should be self-contained, please
> > evaluate if this suites for the application.
> >
> > I copied Marco who might be interested on such project too at least from an
> > user perspective on fuzzing [1].
> >
> > [1] https://lore.kernel.org/all/193e5a-681dfa80-3af-701c0f80@227192887/
> >
> > Thanks,
> 
> I have edited the project description to make it easier for newcomers
> to understand and added a link to mapped-ram.rst:
> https://wiki.qemu.org/Google_Summer_of_Code_2026#Fast_Snapshot_Load
> 
> Feel free to edit the project idea on the wiki.

Looks good, thanks Stefan.

-- 
Peter Xu

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Wed, Jan 14, 2026 at 1:01 PM Marc-André Lureau
<marcandre.lureau@redhat.com> wrote:
> On Tue, Jan 6, 2026 at 1:47 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> Rather than replying to this mail, I sketched some ideas of things I have in mind on the wiki directly:
>
> https://wiki.qemu.org/Internships/ProjectIdeas/RDPUSB

Excellent! This one looks ready to go because it's self-contained.

> https://wiki.qemu.org/Internships/ProjectIdeas/VFIOUSER
> https://wiki.qemu.org/Internships/ProjectIdeas/ModernHMP
> https://wiki.qemu.org/Internships/ProjectIdeas/mkosiTestAssets

These three involve additional maintainers and require consensus
before they can be listed. This way we can be confident that the
intern's work will not be held up later by design discussions from
people who are not yet on board with the idea.

> I will try to reach the various people involved in those related projects to see if they are reasonable proposals.
>
> We have a lot of ideas on the wiki (https://wiki.qemu.org/Internships/ProjectIdeas/), that have various status.. I wonder if they wouldn't be better under qemu.git docs/ with some form, so we could send patches to discuss them instead. Arf, a QEMU Enhancement Proposal, I have too much ideas :)

For the internships, discussing them via email in this thread has
worked well in the past. For a more general QEMU Enhancement Proposal
process, that is a bigger topic for the community since there is
currently no formal process for the development of new features.

I have some thoughts about the vfio-user project idea:

> === First-Class vfio-user Device Support ===
>
> '''Summary:''' Promote QEMU's experimental vfio-user device support to production-ready status by adding comprehensive testing, documentation, migration support, and seamless CLI integration.
>
> Since 2022, QEMU has included `x-vfio-user-server` for running emulated PCI devices in standalone processes using the vfio-user protocol. This enables security isolation, modular device development, and flexible deployment architectures.
>
> However, adoption has been limited due to:
> * '''Experimental status''' - All components use `x-` prefix indicating unstable API

This is a question of whether the command-line interface is stable.
John Levon, Thanos Makatos, and Cédric Le Goater are the maintainers
for vfio-user. I wonder what their thoughts on removing the "x-" are?

> * '''Complex CLI''' - Requires coordinating multiple components (`-machine x-remote` + `-device` + `-object x-vfio-user-server`)
> * '''No live migration''' - Migration explicitly blocked

The vfio-user protocol has adopted the kernel VFIO interface's device
state migration features. In theory the protocol supports migration,
but I don't see QEMU code that implements the protocol features. If my
understanding is correct, then there is a (sub-)project here to
implement live migration protocol features in --device vfio-user-pci
(the proxy) as well as in --object x-vfio-user-server (QEMU's server)?

> * '''Limited testing''' - Only one functional smoke test exists
> * '''Documentation''' - No usage guide or troubleshooting docs
>
> This project aims to make vfio-user a first-class QEMU feature.
>
> '''Goal:''' Enable out-of-process device emulation with a single CLI option.
>
> '''Current (complex):'''
> <pre>
> # Server process (full QEMU instance):
> qemu-system-x86_64 -machine x-remote,vfio-user=on \
>   -device pci-serial,id=serial0 \
>   -object x-vfio-user-server,id=vfu0,type=unix,path=/tmp/serial.sock,device=serial0
>
> # Client process (main VM):
> qemu-system-x86_64 ... -device vfio-user-pci,socket=/tmp/serial.sock
> </pre>
>
> '''Proposed:'''
> <pre>
> # Single option spawns all capable devices out-of-process automatically
> qemu-system-x86_64 -vfio-user \
>   -device pci-serial \
>   -device virtio-net-pci \
>   -device pvpanic-pci \

At first I thought this was about launching third-party vfio-user
device servers from the QEMU command-line, but later I realized it's
only about running QEMU's PCI device emulation in separate processes.

>   ...
> # QEMU automatically:
> # - Identifies vfio-user capable devices
> # - Spawns device server processes
> # - Connects via vfio-user protocol
> # - Manages lifecycle (startup, shutdown, crash recovery)
> </pre>
>
> '''Implementation:'''
> * Add global `-vfio-user` CLI option
> * Identify devices capable of out-of-process emulation (all PCI devices initially)
> * Automatically spawn server process for each capable device
> * Create internal socket connections (e.g., `/tmp/qemu-vfio-user-<pid>-<device>.sock`)
> * Replace device with `vfio-user-pci` client transparently
> * Handle process lifecycle: spawn, health monitoring, graceful shutdown, crash recovery
> * Optional: `-vfio-user=<device-list>` to select specific devices

Monitor commands don't work as expected in this mode since the main
VM's QMP server is unaware of the vfio-user device server's QMP
servers. How should QMP work for automatically spawned devices? I
think approaches that try to aggregate query-* command results or make
it appear that the devices are part of QEMU become complex quickly.

Users choosing vfio-user for process isolation (security) need to
launch vfio-user device servers before launching QEMU in order to
achieve principle of least privilege (e.g. pass file descriptors only
to the server and not to the main VM process).

> '''Goal:''' Add test suite covering more vfio-user devices and functionalities
>
> Currently, a single smoke test (`tests/functional/x86_64/test_vfio_user_client.py`)
>
> '''Test devices:'''
> * `pvpanic-pci` - Minimal device, no interrupts
> * `pci-serial` - Simple with INTx interrupt
> * `virtio-*` - More complex devices with DMA

Nice.

> '''Goal:''' Documentation for users and developers
>
> ** Quick start examples
> ** CLI reference
> ** Common use cases (security isolation, modular development)
> ** Troubleshooting guide
> ** When to use vfio-user
> ** Comparison with other solutions (vhost-user, usbredir, cacard, swtpm...)
> ** Performance considerations

Yes!

> == Stretch goals ==
>
> * Migration support
> * Hot-plug support
> * Support for non-PCI devices
>
> '''Links:'''
> * https://www.qemu.org/docs/master/interop/vfio-user.html - vfio-user protocol specification
> * https://github.com/nutanix/libvfio-user - libvfio-user library
>
> '''Details:'''
> * Skill level: advanced
> * Language: C
> * Mentor: Marc-André Lureau <marcandre.lureau@redhat.com> (elmarco on IRC)
> * VFIO-USER maintainers?
> * Suggested by: Marc-André Lureau

Stefan

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

Hi Marc-André,
I haven't seen discussion about the project ideas you posted, so I'll
try to kick it off here for the mkosi idea here.

Thomas: Would you like to co-mentor the following project with
Marc-André? Also, do you have any concerns about the project idea from
the maintainer perspective?

=== Reproducible Test Image Building with mkosi ===

'''Summary:''' Build minimal, reproducible test images for QEMU
functional tests using mkosi, replacing ad-hoc pre-built assets with a
standardized, maintainable build system.

QEMU's functional test suite (`tests/functional/`) relies on pre-built
images fetched from various external sources including Debian
archives, Fedora repositories, GitHub repositories (e.g.,
qemu-ppc-boot, linux-build-test), Linaro artifacts, and others. While
this approach works, it has several drawbacks:

* '''Reproducibility issues''': External sources may change,
disappear, or serve different content over time
* '''Opacity''': The exact build configuration of these images is
often undocumented or unknown
* '''Maintenance burden''': When images need updates (fixes, new
features), there's no standardized process
* '''Inconsistency''': Images come from different sources with varying
quality, size, and configuration

This project proposes using mkosi to build minimal, reproducible test
images directly from distribution packages. mkosi is a tool for
building clean OS images from distribution packages, with excellent
support for Fedora and other distributions. It should be able to
produces deterministic outputs.

The Ouroboros has finally caught its tail: QEMU adopts mkosi for
testing, while mkosi continues using QEMU to exist.

'''Project Goals:'''

# Create mkosi configurations for building minimal bootable images for
x86_64 and aarch64 architectures using Fedora packages
# Integrate with the existing Asset framework in
`tests/functional/qemu_test/asset.py` to seamlessly use mkosi-built
images alongside existing assets
# Set up GitLab CI pipelines to automatically build, hash, and publish
images when configurations change
# Document the image building process including comparison with
existing tuxrun/tuxboot assets (which remain out of scope for
replacement)
# Migrate selected tests from external pre-built images to mkosi-built
equivalents

'''Links:'''
* [https://wiki.qemu.org/Testing/Functional QEMU Functional Testing
documentation]
* [https://github.com/systemd/mkosi mkosi project]
* [https://gitlab.com/qemu-project/qemu QEMU GitLab repository]
* [https://www.qemu.org/docs/master/devel/testing.html QEMU Testing
documentation]
* [https://mkosi.systemd.io/ mkosi documentation]

'''Details:'''
* Skill level: intermediate
* Language: Python (test framework), Shell/mkosi configuration
* Mentor: Marc-André Lureau <marcandre.lureau@redhat.com> (elmarco)
* Thomas Huth ?
* Suggested by: Marc-André Lureau

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> Hi Marc-André,
> I haven't seen discussion about the project ideas you posted, so I'll
> try to kick it off here for the mkosi idea here.
> 
> Thomas: Would you like to co-mentor the following project with
> Marc-André? Also, do you have any concerns about the project idea from
> the maintainer perspective?

The idea of being able to build test images is very attractive,
however, actual deployment of any impl will run into the same
constraint we've always had. If we host disk images, then we
have the responsibility to host the complete & corresponding
source. This is a significant undertaking that we've never been
wished to take on. IMHO publishing images in GitLab CI won't
satisfy the license requireemnts.


> === Reproducible Test Image Building with mkosi ===
> 
> '''Summary:''' Build minimal, reproducible test images for QEMU
> functional tests using mkosi, replacing ad-hoc pre-built assets with a
> standardized, maintainable build system.
> 
> QEMU's functional test suite (`tests/functional/`) relies on pre-built
> images fetched from various external sources including Debian
> archives, Fedora repositories, GitHub repositories (e.g.,
> qemu-ppc-boot, linux-build-test), Linaro artifacts, and others. While
> this approach works, it has several drawbacks:
> 
> * '''Reproducibility issues''': External sources may change,
> disappear, or serve different content over time
> * '''Opacity''': The exact build configuration of these images is
> often undocumented or unknown
> * '''Maintenance burden''': When images need updates (fixes, new
> features), there's no standardized process
> * '''Inconsistency''': Images come from different sources with varying
> quality, size, and configuration
> 
> This project proposes using mkosi to build minimal, reproducible test
> images directly from distribution packages. mkosi is a tool for
> building clean OS images from distribution packages, with excellent
> support for Fedora and other distributions. It should be able to
> produces deterministic outputs.
> 
> The Ouroboros has finally caught its tail: QEMU adopts mkosi for
> testing, while mkosi continues using QEMU to exist.
> 
> '''Project Goals:'''
> 
> # Create mkosi configurations for building minimal bootable images for
> x86_64 and aarch64 architectures using Fedora packages
> # Integrate with the existing Asset framework in
> `tests/functional/qemu_test/asset.py` to seamlessly use mkosi-built
> images alongside existing assets
> # Set up GitLab CI pipelines to automatically build, hash, and publish
> images when configurations change
> # Document the image building process including comparison with
> existing tuxrun/tuxboot assets (which remain out of scope for
> replacement)
> # Migrate selected tests from external pre-built images to mkosi-built
> equivalents
> 
> '''Links:'''
> * [https://wiki.qemu.org/Testing/Functional QEMU Functional Testing
> documentation]
> * [https://github.com/systemd/mkosi mkosi project]
> * [https://gitlab.com/qemu-project/qemu QEMU GitLab repository]
> * [https://www.qemu.org/docs/master/devel/testing.html QEMU Testing
> documentation]
> * [https://mkosi.systemd.io/ mkosi documentation]
> 
> '''Details:'''
> * Skill level: intermediate
> * Language: Python (test framework), Shell/mkosi configuration
> * Mentor: Marc-André Lureau <marcandre.lureau@redhat.com> (elmarco)
> * Thomas Huth ?
> * Suggested by: Marc-André Lureau
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Call for GSoC internship project ideas

[Thomas Huth]

On 20/01/2026 22.50, Daniel P. Berrangé wrote:
> On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
>> Hi Marc-André,
>> I haven't seen discussion about the project ideas you posted, so I'll
>> try to kick it off here for the mkosi idea here.
>>
>> Thomas: Would you like to co-mentor the following project with
>> Marc-André? Also, do you have any concerns about the project idea from
>> the maintainer perspective?
> 
> The idea of being able to build test images is very attractive,
> however, actual deployment of any impl will run into the same
> constraint we've always had. If we host disk images, then we
> have the responsibility to host the complete & corresponding
> source. This is a significant undertaking that we've never been
> wished to take on. IMHO publishing images in GitLab CI won't
> satisfy the license requireemnts.
I agree, and I think if we go ahead with this project, we should not use the 
gitlab-CI to build and provide these images. It would be better to build the 
images on the host that runs "make check", similar to the precaching for 
assets that we currently do. The built images could then be stored in the 
local asset cache so you don't have to rebuild them again the next time your 
run "make check". Does that sound practicable to you?

  Thomas

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> Hi Marc-André,
> I haven't seen discussion about the project ideas you posted, so I'll
> try to kick it off here for the mkosi idea here.
> 
> Thomas: Would you like to co-mentor the following project with
> Marc-André? Also, do you have any concerns about the project idea from
> the maintainer perspective?
> 
> === Reproducible Test Image Building with mkosi ===

> This project proposes using mkosi to build minimal, reproducible test
> images directly from distribution packages. mkosi is a tool for
> building clean OS images from distribution packages, with excellent
> support for Fedora and other distributions. It should be able to
> produces deterministic outputs.

Aside from what I mentioned already, the other issue I anticipate
with mkosi is the mismatch between what hardware QEMU needs to be
able to cover, vs what hardware the distros actually support.

Fedora in particular is pretty narrow in its coverage. Debian is
considerably broader.

Neither will support all the QEMU targets, let alone all the
machine types within the target.


While there is value in testing a full blown OS image, IMHO,
for most of what we need it is considerable overkill, and
thus makes functional tests slower than they would otherwise
need to be.

IMHO, our baseline for functional testing images ought to be
a Linux Kconfig recipe used to build a dedicate kernel, plus
a busybox build for the target.

This would let us create either a self contained initrd, or
a tiny root disk, both of which would reliably boot in a
barely more than a second or two, even under TCG.

This would have a number of other benefits

 * Not dependent on distros supporting the given QEMU
   target and machine type. As long as a Linux port
   exists and busybox compiles, we can test it
 
 * Identical test image functionality for every single
   target and machine type. No hodge-podge of different
   3rd party guest OS.

 * Stable forever, with all changes entirely under
   our own control. No distro changes that arbitrarily
   break our CI.

 * Easier to debug when it breaks, since there would
   be a small well defined set of logic running in
   the guest userspace

 * Fairly easy for QEMU to provide the complete and
   corresponding source for any binary images, since
   we've built it all from scratch

 * Tiny & fast downloads of pre-built images.


This would not eliminate the need for testing real OS images,
but would significantly downgrade their importance.

Functional tests could be in three groups - 'quick', as today,
'slow' the smoke tests with our miny kernel+busybox, 'thorough'
the full OS images.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Call for GSoC internship project ideas

[Marc-André Lureau]

Hi

On Thu, Jan 22, 2026 at 2:14 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> > Hi Marc-André,
> > I haven't seen discussion about the project ideas you posted, so I'll
> > try to kick it off here for the mkosi idea here.
> >
> > Thomas: Would you like to co-mentor the following project with
> > Marc-André? Also, do you have any concerns about the project idea from
> > the maintainer perspective?
> >
> > === Reproducible Test Image Building with mkosi ===
>
> > This project proposes using mkosi to build minimal, reproducible test
> > images directly from distribution packages. mkosi is a tool for
> > building clean OS images from distribution packages, with excellent
> > support for Fedora and other distributions. It should be able to
> > produces deterministic outputs.
>
> Aside from what I mentioned already, the other issue I anticipate
> with mkosi is the mismatch between what hardware QEMU needs to be
> able to cover, vs what hardware the distros actually support.
>
> Fedora in particular is pretty narrow in its coverage. Debian is
> considerably broader.
>
> Neither will support all the QEMU targets, let alone all the
> machine types within the target.


That's right, the goal here is not to cover all possible images though.

I picked Fedora here as an example, because it is the best supported
distribution in mkosi.


>
>
> While there is value in testing a full blown OS image, IMHO,
> for most of what we need it is considerable overkill, and
> thus makes functional tests slower than they would otherwise
> need to be.

mkosi can produce initrd images, which can be small enough and
customizable. Although I lack the details of what is possible, this is
part of the project research.

Imho, building all images from scratch cannot be sustainable.

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 02:22:28PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Jan 22, 2026 at 2:14 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> > > Hi Marc-André,
> > > I haven't seen discussion about the project ideas you posted, so I'll
> > > try to kick it off here for the mkosi idea here.
> > >
> > > Thomas: Would you like to co-mentor the following project with
> > > Marc-André? Also, do you have any concerns about the project idea from
> > > the maintainer perspective?
> > >
> > > === Reproducible Test Image Building with mkosi ===
> >
> > > This project proposes using mkosi to build minimal, reproducible test
> > > images directly from distribution packages. mkosi is a tool for
> > > building clean OS images from distribution packages, with excellent
> > > support for Fedora and other distributions. It should be able to
> > > produces deterministic outputs.
> >
> > Aside from what I mentioned already, the other issue I anticipate
> > with mkosi is the mismatch between what hardware QEMU needs to be
> > able to cover, vs what hardware the distros actually support.
> >
> > Fedora in particular is pretty narrow in its coverage. Debian is
> > considerably broader.
> >
> > Neither will support all the QEMU targets, let alone all the
> > machine types within the target.
> 
> 
> That's right, the goal here is not to cover all possible images though.
> 
> I picked Fedora here as an example, because it is the best supported
> distribution in mkosi.

IMHO to be worth the effort of integrating mkosi *and* maintaining its
use in QEMU long term, it has to address a broad set of problems that
we face in the functional tests.

IMHO the inherant dependency on distros is the underlying problem
we have, as we try to achieve testing coverage across all the
machine types in QEMU.  It leads us to having a random selection
of different approaches, and mkosi does not look like it will
reduce that problem, or help us fill in the gaps we have.

> > While there is value in testing a full blown OS image, IMHO,
> > for most of what we need it is considerable overkill, and
> > thus makes functional tests slower than they would otherwise
> > need to be.
> 
> mkosi can produce initrd images, which can be small enough and
> customizable. Although I lack the details of what is possible, this is
> part of the project research.
> 
> Imho, building all images from scratch cannot be sustainable.

I'd say the opposite - relying on distros, whether using mkosi
or not, is not sustainable.

Once we have written some scripts that can build gcc, binutils, linux,
busybox we've opened the door to be able to support every machine type
on every target, provided there has been a gcc/binutils/linux port at
some time (which covers practically everything). Adding new machines
becomes cheap then - just a matter of identifying the Linux Kconfig
settings, and everything else stays the same. Adding new targets means
adding a new binutils build target, which should again we relatively
cheap, and also infrequent. This has potential to be massively more
sustainable than a reliance on distros, and should put us on a pathway
that would let us cover almost everything we ship.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Call for GSoC internship project ideas

[Peter Maydell]

On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> Once we have written some scripts that can build gcc, binutils, linux,
> busybox we've opened the door to be able to support every machine type
> on every target, provided there has been a gcc/binutils/linux port at
> some time (which covers practically everything). Adding new machines
> becomes cheap then - just a matter of identifying the Linux Kconfig
> settings, and everything else stays the same. Adding new targets means
> adding a new binutils build target, which should again we relatively
> cheap, and also infrequent. This has potential to be massively more
> sustainable than a reliance on distros, and should put us on a pathway
> that would let us cover almost everything we ship.

Isn't that essentially reimplementing half of buildroot, or the
system image builder that Rob Landley uses to produce toybox
test images ?

thanks
-- PMM

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
> On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > Once we have written some scripts that can build gcc, binutils, linux,
> > busybox we've opened the door to be able to support every machine type
> > on every target, provided there has been a gcc/binutils/linux port at
> > some time (which covers practically everything). Adding new machines
> > becomes cheap then - just a matter of identifying the Linux Kconfig
> > settings, and everything else stays the same. Adding new targets means
> > adding a new binutils build target, which should again we relatively
> > cheap, and also infrequent. This has potential to be massively more
> > sustainable than a reliance on distros, and should put us on a pathway
> > that would let us cover almost everything we ship.
> 
> Isn't that essentially reimplementing half of buildroot, or the
> system image builder that Rob Landley uses to produce toybox
> test images ?

If we can use existing tools to achieve this, that's fine.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Call for GSoC internship project ideas

[Marc-André Lureau]

Hi

On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
> > On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > Once we have written some scripts that can build gcc, binutils, linux,
> > > busybox we've opened the door to be able to support every machine type
> > > on every target, provided there has been a gcc/binutils/linux port at
> > > some time (which covers practically everything). Adding new machines
> > > becomes cheap then - just a matter of identifying the Linux Kconfig
> > > settings, and everything else stays the same. Adding new targets means
> > > adding a new binutils build target, which should again we relatively
> > > cheap, and also infrequent. This has potential to be massively more
> > > sustainable than a reliance on distros, and should put us on a pathway
> > > that would let us cover almost everything we ship.
> >
> > Isn't that essentially reimplementing half of buildroot, or the
> > system image builder that Rob Landley uses to produce toybox
> > test images ?
>
> If we can use existing tools to achieve this, that's fine.
>

Imho, both approaches are complementary. Building images from scratch,
like toybox, to cover esoteric minimal systems. And more complete and
common OSes with mkosi which allows you to have things like python,
mesa, networking, systemd, tpm tools, etc for testing.. We don't want
to build that from scratch, do we?

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 03:28:24PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
> > > On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > > Once we have written some scripts that can build gcc, binutils, linux,
> > > > busybox we've opened the door to be able to support every machine type
> > > > on every target, provided there has been a gcc/binutils/linux port at
> > > > some time (which covers practically everything). Adding new machines
> > > > becomes cheap then - just a matter of identifying the Linux Kconfig
> > > > settings, and everything else stays the same. Adding new targets means
> > > > adding a new binutils build target, which should again we relatively
> > > > cheap, and also infrequent. This has potential to be massively more
> > > > sustainable than a reliance on distros, and should put us on a pathway
> > > > that would let us cover almost everything we ship.
> > >
> > > Isn't that essentially reimplementing half of buildroot, or the
> > > system image builder that Rob Landley uses to produce toybox
> > > test images ?
> >
> > If we can use existing tools to achieve this, that's fine.
> >
> 
> Imho, both approaches are complementary. Building images from scratch,
> like toybox, to cover esoteric minimal systems. And more complete and
> common OSes with mkosi which allows you to have things like python,
> mesa, networking, systemd, tpm tools, etc for testing.. We don't want
> to build that from scratch, do we?

To some extent they are complementary, but in terms of what we're doing
with functional tests today, IMHO it could be almost entirely done
with buildroot images. Few of our current tests leverage significant
userspace functionality inside the guest. I'd see buildroot as being
able to provide common baseline that we could potentially even declare
to be a pre-requisite for introducing a new machine type to QEMU.

A handful of current things might need a full 3rd party distro image,
but not many, hence IMHO the bigger benefit to QEMU comes from investing
in a buildroot like approach rather than mkosi, at least at the current
time.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Call for GSoC internship project ideas

[Alex Bennée]

Marc-André Lureau <marcandre.lureau@redhat.com> writes:

> Hi
>
> On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
>> > On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> > > Once we have written some scripts that can build gcc, binutils, linux,
>> > > busybox we've opened the door to be able to support every machine type
>> > > on every target, provided there has been a gcc/binutils/linux port at
>> > > some time (which covers practically everything). Adding new machines
>> > > becomes cheap then - just a matter of identifying the Linux Kconfig
>> > > settings, and everything else stays the same. Adding new targets means
>> > > adding a new binutils build target, which should again we relatively
>> > > cheap, and also infrequent. This has potential to be massively more
>> > > sustainable than a reliance on distros, and should put us on a pathway
>> > > that would let us cover almost everything we ship.
>> >
>> > Isn't that essentially reimplementing half of buildroot, or the
>> > system image builder that Rob Landley uses to produce toybox
>> > test images ?
>>
>> If we can use existing tools to achieve this, that's fine.
>>
>
> Imho, both approaches are complementary. Building images from scratch,
> like toybox, to cover esoteric minimal systems. And more complete and
> common OSes with mkosi which allows you to have things like python,
> mesa, networking, systemd, tpm tools, etc for testing.. We don't want
> to build that from scratch, do we?

Well for vkmark it was easier to update the mesa in buildroot for the
latest bits for testing venus than wait for the distros to catch up with
library support.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC internship project ideas

[Pierrick Bouvier]

On 1/22/26 3:28 AM, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>
>> On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
>>> On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>> Once we have written some scripts that can build gcc, binutils, linux,
>>>> busybox we've opened the door to be able to support every machine type
>>>> on every target, provided there has been a gcc/binutils/linux port at
>>>> some time (which covers practically everything). Adding new machines
>>>> becomes cheap then - just a matter of identifying the Linux Kconfig
>>>> settings, and everything else stays the same. Adding new targets means
>>>> adding a new binutils build target, which should again we relatively
>>>> cheap, and also infrequent. This has potential to be massively more
>>>> sustainable than a reliance on distros, and should put us on a pathway
>>>> that would let us cover almost everything we ship.
>>>
>>> Isn't that essentially reimplementing half of buildroot, or the
>>> system image builder that Rob Landley uses to produce toybox
>>> test images ?
>>
>> If we can use existing tools to achieve this, that's fine.
>>
> 
> Imho, both approaches are complementary. Building images from scratch,
> like toybox, to cover esoteric minimal systems. And more complete and
> common OSes with mkosi which allows you to have things like python,
> mesa, networking, systemd, tpm tools, etc for testing.. We don't want
> to build that from scratch, do we?
> 

I ran into this need recently, and simply used podman (or docker) for 
this purpose.

$ podman build -t rootfs - < Dockerfile
$ container=$(podman create rootfs)
$ podman export -o /dev/stdout $container |
/sbin/mke2fs -t ext4 -d - out.ext4 10g
$ podman rm -f $container

It allows to create image for any distro (used it for alpine and 
debian), as long as they publish a docker container. As well, it gives 
flexibility to have a custom init, skipping a lengthy emulated boot with 
a full system. As a bonus, it's quick to build, and does not require 
recompiling the world to get something.

You can debug things too by running the container on your host machine, 
which is convenient.

I took a look at bootc, but was not really convinced of what it added 
for my use case compared to the 4 commands above.

Just my 2 cents,
Pierrick

Re: Call for GSoC internship project ideas

[Marc-André Lureau]

Hi

On Thu, Jan 22, 2026 at 7:46 PM Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
>
> On 1/22/26 3:28 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>
> >> On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
> >>> On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>>> Once we have written some scripts that can build gcc, binutils, linux,
> >>>> busybox we've opened the door to be able to support every machine type
> >>>> on every target, provided there has been a gcc/binutils/linux port at
> >>>> some time (which covers practically everything). Adding new machines
> >>>> becomes cheap then - just a matter of identifying the Linux Kconfig
> >>>> settings, and everything else stays the same. Adding new targets means
> >>>> adding a new binutils build target, which should again we relatively
> >>>> cheap, and also infrequent. This has potential to be massively more
> >>>> sustainable than a reliance on distros, and should put us on a pathway
> >>>> that would let us cover almost everything we ship.
> >>>
> >>> Isn't that essentially reimplementing half of buildroot, or the
> >>> system image builder that Rob Landley uses to produce toybox
> >>> test images ?
> >>
> >> If we can use existing tools to achieve this, that's fine.
> >>
> >
> > Imho, both approaches are complementary. Building images from scratch,
> > like toybox, to cover esoteric minimal systems. And more complete and
> > common OSes with mkosi which allows you to have things like python,
> > mesa, networking, systemd, tpm tools, etc for testing.. We don't want
> > to build that from scratch, do we?
> >
>
> I ran into this need recently, and simply used podman (or docker) for
> this purpose.
>
> $ podman build -t rootfs - < Dockerfile
> $ container=$(podman create rootfs)
> $ podman export -o /dev/stdout $container |
> /sbin/mke2fs -t ext4 -d - out.ext4 10g
> $ podman rm -f $container
>
> It allows to create image for any distro (used it for alpine and
> debian), as long as they publish a docker container. As well, it gives
> flexibility to have a custom init, skipping a lengthy emulated boot with
> a full system. As a bonus, it's quick to build, and does not require
> recompiling the world to get something.
>
> You can debug things too by running the container on your host machine,
> which is convenient.
>

Very nice! I didn't realize you could export and reuse a container that way.

I wonder how this workflow can be extended and compare to mkosi
(beside the limitation to produce tar/fs image)

For qemu VM testing, it would fit better along with our Dockerfile &
lcitool usage.

I wish a tool would help to (cross) create & boot such (reproducible)
images & vm easily.


> I took a look at bootc, but was not really convinced of what it added
> for my use case compared to the 4 commands above.
>

Having a regular VM bootable image could be desirable for some cases
(tpm, secure boot testing for ex).

--
Marc-André Lureau

Re: Call for GSoC internship project ideas

[Pierrick Bouvier]

On 1/23/26 12:44 AM, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Jan 22, 2026 at 7:46 PM Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>>
>> On 1/22/26 3:28 AM, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>>
>>>> On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
>>>>> On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>>>> Once we have written some scripts that can build gcc, binutils, linux,
>>>>>> busybox we've opened the door to be able to support every machine type
>>>>>> on every target, provided there has been a gcc/binutils/linux port at
>>>>>> some time (which covers practically everything). Adding new machines
>>>>>> becomes cheap then - just a matter of identifying the Linux Kconfig
>>>>>> settings, and everything else stays the same. Adding new targets means
>>>>>> adding a new binutils build target, which should again we relatively
>>>>>> cheap, and also infrequent. This has potential to be massively more
>>>>>> sustainable than a reliance on distros, and should put us on a pathway
>>>>>> that would let us cover almost everything we ship.
>>>>>
>>>>> Isn't that essentially reimplementing half of buildroot, or the
>>>>> system image builder that Rob Landley uses to produce toybox
>>>>> test images ?
>>>>
>>>> If we can use existing tools to achieve this, that's fine.
>>>>
>>>
>>> Imho, both approaches are complementary. Building images from scratch,
>>> like toybox, to cover esoteric minimal systems. And more complete and
>>> common OSes with mkosi which allows you to have things like python,
>>> mesa, networking, systemd, tpm tools, etc for testing.. We don't want
>>> to build that from scratch, do we?
>>>
>>
>> I ran into this need recently, and simply used podman (or docker) for
>> this purpose.
>>
>> $ podman build -t rootfs - < Dockerfile
>> $ container=$(podman create rootfs)
>> $ podman export -o /dev/stdout $container |
>> /sbin/mke2fs -t ext4 -d - out.ext4 10g
>> $ podman rm -f $container
>>
>> It allows to create image for any distro (used it for alpine and
>> debian), as long as they publish a docker container. As well, it gives
>> flexibility to have a custom init, skipping a lengthy emulated boot with
>> a full system. As a bonus, it's quick to build, and does not require
>> recompiling the world to get something.
>>
>> You can debug things too by running the container on your host machine,
>> which is convenient.
>>
> 
> Very nice! I didn't realize you could export and reuse a container that way.
>

It's a just a filesystem, so you're free to include what you want. An 
advantage on custom solutions is that Dockerfile is a standardized format.

> I wonder how this workflow can be extended and compare to mkosi
> (beside the limitation to produce tar/fs image)
>

mkosi takes care of more things for you, like setting up users, probably 
supports partitioning your disk, and make it bootable. See it as 
something like debootstrap + install.
The container based approach above give you an ext4 filesystem, the rest 
is up to you.

> For qemu VM testing, it would fit better along with our Dockerfile &
> lcitool usage.
>

It's nice and easy to prototype indeed. As well, unrelated, but I think 
it's better for everyone to spend time learning Dockerfiles instead of 
an ad-hoc solution QEMU wants to use. The worse would be custom python 
scripts reinventing the wheel and recompiling everything: long to 
iterate and impossible to decipher except for the one who wrote it.

> I wish a tool would help to (cross) create & boot such (reproducible)
> images & vm easily.
> 

I was looking exactly at this, and I've been surprised that nobody 
except bootc tried reusing existing containers: it seems to be a perfect 
match. Beyond the convenience, you get build caching for free, which is 
very important when you iterate on system images. And you can host the 
result directly and for free on dockerhub, even if that's several GB.

Bootc forces the usage of a specific "base" image, which, IMHO, goes 
against what people should expect. Now, instead of having a normal 
Dockerfile, you have a Dockerfile based on a black box you can't modify 
easily. If I'm wrong and if someone is familiar with bootc here, I would 
be happy to hear the opposite.

> 
>> I took a look at bootc, but was not really convinced of what it added
>> for my use case compared to the 4 commands above.
>>
> 
> Having a regular VM bootable image could be desirable for some cases
> (tpm, secure boot testing for ex).
> 
> --
> Marc-André Lureau

All that said, containers are just a suggestion. If mkosi is a good 
tool, I would be happy to see it used. Just avoid going down the rabbit 
hole reimplementing everything like it has been suggested on this 
thread: we would not have one problem only, but two problems instead.

Regards,
Pierrick

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Fri, Jan 23, 2026 at 3:44 AM Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Thu, Jan 22, 2026 at 7:46 PM Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
> >
> > On 1/22/26 3:28 AM, Marc-André Lureau wrote:
> > > Hi
> > >
> > > On Thu, Jan 22, 2026 at 2:57 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >>
> > >> On Thu, Jan 22, 2026 at 10:54:42AM +0000, Peter Maydell wrote:
> > >>> On Thu, 22 Jan 2026 at 10:40, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >>>> Once we have written some scripts that can build gcc, binutils, linux,
> > >>>> busybox we've opened the door to be able to support every machine type
> > >>>> on every target, provided there has been a gcc/binutils/linux port at
> > >>>> some time (which covers practically everything). Adding new machines
> > >>>> becomes cheap then - just a matter of identifying the Linux Kconfig
> > >>>> settings, and everything else stays the same. Adding new targets means
> > >>>> adding a new binutils build target, which should again we relatively
> > >>>> cheap, and also infrequent. This has potential to be massively more
> > >>>> sustainable than a reliance on distros, and should put us on a pathway
> > >>>> that would let us cover almost everything we ship.
> > >>>
> > >>> Isn't that essentially reimplementing half of buildroot, or the
> > >>> system image builder that Rob Landley uses to produce toybox
> > >>> test images ?
> > >>
> > >> If we can use existing tools to achieve this, that's fine.
> > >>
> > >
> > > Imho, both approaches are complementary. Building images from scratch,
> > > like toybox, to cover esoteric minimal systems. And more complete and
> > > common OSes with mkosi which allows you to have things like python,
> > > mesa, networking, systemd, tpm tools, etc for testing.. We don't want
> > > to build that from scratch, do we?
> > >
> >
> > I ran into this need recently, and simply used podman (or docker) for
> > this purpose.
> >
> > $ podman build -t rootfs - < Dockerfile
> > $ container=$(podman create rootfs)
> > $ podman export -o /dev/stdout $container |
> > /sbin/mke2fs -t ext4 -d - out.ext4 10g
> > $ podman rm -f $container
> >
> > It allows to create image for any distro (used it for alpine and
> > debian), as long as they publish a docker container. As well, it gives
> > flexibility to have a custom init, skipping a lengthy emulated boot with
> > a full system. As a bonus, it's quick to build, and does not require
> > recompiling the world to get something.
> >
> > You can debug things too by running the container on your host machine,
> > which is convenient.
> >
>
> Very nice! I didn't realize you could export and reuse a container that way.
>
> I wonder how this workflow can be extended and compare to mkosi
> (beside the limitation to produce tar/fs image)
>
> For qemu VM testing, it would fit better along with our Dockerfile &
> lcitool usage.
>
> I wish a tool would help to (cross) create & boot such (reproducible)
> images & vm easily.

Hi Marc-André,
I would like to submit QEMU's GSoC application in the next day or two.
A minimum of 4 project ideas is mentioned in the latest guidelines
from Google and we're currently at 3 ideas. Do you want to update the
project idea based on the feedback so we can add it to the list?
https://wiki.qemu.org/Internships/ProjectIdeas/mkosiTestAssets

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Stefano Garzarella]

On Mon, 26 Jan 2026 at 23:29, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Hi Marc-André,
> I would like to submit QEMU's GSoC application in the next day or two.
> A minimum of 4 project ideas is mentioned in the latest guidelines
> from Google and we're currently at 3 ideas. Do you want to update the
> project idea based on the feedback so we can add it to the list?
> https://wiki.qemu.org/Internships/ProjectIdeas/mkosiTestAssets

Hi Stefan,
FYI we are going to submit 2 projects for SVSM and 1 for rust-vmm
(virtio-rtc device) soon.

Sorry for the delay,
Stefano

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Tue, Jan 27, 2026 at 3:35 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> On Mon, 26 Jan 2026 at 23:29, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > Hi Marc-André,
> > I would like to submit QEMU's GSoC application in the next day or two.
> > A minimum of 4 project ideas is mentioned in the latest guidelines
> > from Google and we're currently at 3 ideas. Do you want to update the
> > project idea based on the feedback so we can add it to the list?
> > https://wiki.qemu.org/Internships/ProjectIdeas/mkosiTestAssets
>
> Hi Stefan,
> FYI we are going to submit 2 projects for SVSM and 1 for rust-vmm
> (virtio-rtc device) soon.

Great, I'm looking forward to adding them.

Stefan

Re: Call for GSoC internship project ideas

[Thomas Huth]

On 22/01/2026 11.14, Daniel P. Berrangé wrote:
> On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
>> Hi Marc-André,
>> I haven't seen discussion about the project ideas you posted, so I'll
>> try to kick it off here for the mkosi idea here.
>>
>> Thomas: Would you like to co-mentor the following project with
>> Marc-André? Also, do you have any concerns about the project idea from
>> the maintainer perspective?

I'm fine with co-mentoring the project, but could you do me a favour and add 
some wording about AI tools to 
https://wiki.qemu.org/Google_Summer_of_Code_2026 to set the expectations 
right? Since we don't allow AI generated code in QEMU, I'd appreciate if we 
could state this in a prominent place here to avoid that some people think 
they could get some quick money here by using AI tools, just to finally 
discover that AI generated code is not allowed in the QEMU project. Thanks!

> IMHO, our baseline for functional testing images ought to be
> a Linux Kconfig recipe used to build a dedicate kernel, plus
> a busybox build for the target.

Not sure if we want to add kernel compilation time to the functional tests 
(even if it's only done once during the initial build)...? That could easily 
sum up to a couple of hours for a fresh checkout of QEMU...

  Thomas

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 11:43:35AM +0100, Thomas Huth wrote:
> On 22/01/2026 11.14, Daniel P. Berrangé wrote:
> > On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> > > Hi Marc-André,
> > > I haven't seen discussion about the project ideas you posted, so I'll
> > > try to kick it off here for the mkosi idea here.
> > > 
> > > Thomas: Would you like to co-mentor the following project with
> > > Marc-André? Also, do you have any concerns about the project idea from
> > > the maintainer perspective?
> 
> I'm fine with co-mentoring the project, but could you do me a favour and add
> some wording about AI tools to
> https://wiki.qemu.org/Google_Summer_of_Code_2026 to set the expectations
> right? Since we don't allow AI generated code in QEMU, I'd appreciate if we
> could state this in a prominent place here to avoid that some people think
> they could get some quick money here by using AI tools, just to finally
> discover that AI generated code is not allowed in the QEMU project. Thanks!
> 
> > IMHO, our baseline for functional testing images ought to be
> > a Linux Kconfig recipe used to build a dedicate kernel, plus
> > a busybox build for the target.
> 
> Not sure if we want to add kernel compilation time to the functional tests
> (even if it's only done once during the initial build)...? That could easily
> sum up to a couple of hours for a fresh checkout of QEMU...

That's absolutely *NOT* what I was suggesting.

We should have a 'qemu-test-images.git' repository that maintains all
the recipes, with CI jobs to build and publish them (along with corresponding
source). Those prebuilt images would be consumed by QEMU functional tests.
This would be quicker than what we have today, as the images downloaded by
functional tests could be an order of magnitude smaller, and boot more
quickly too.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Call for GSoC internship project ideas

[Thomas Huth]

On 22/01/2026 11.48, Daniel P. Berrangé wrote:
> On Thu, Jan 22, 2026 at 11:43:35AM +0100, Thomas Huth wrote:
>> On 22/01/2026 11.14, Daniel P. Berrangé wrote:
>>> On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
>>>> Hi Marc-André,
>>>> I haven't seen discussion about the project ideas you posted, so I'll
>>>> try to kick it off here for the mkosi idea here.
>>>>
>>>> Thomas: Would you like to co-mentor the following project with
>>>> Marc-André? Also, do you have any concerns about the project idea from
>>>> the maintainer perspective?
>>
>> I'm fine with co-mentoring the project, but could you do me a favour and add
>> some wording about AI tools to
>> https://wiki.qemu.org/Google_Summer_of_Code_2026 to set the expectations
>> right? Since we don't allow AI generated code in QEMU, I'd appreciate if we
>> could state this in a prominent place here to avoid that some people think
>> they could get some quick money here by using AI tools, just to finally
>> discover that AI generated code is not allowed in the QEMU project. Thanks!
>>
>>> IMHO, our baseline for functional testing images ought to be
>>> a Linux Kconfig recipe used to build a dedicate kernel, plus
>>> a busybox build for the target.
>>
>> Not sure if we want to add kernel compilation time to the functional tests
>> (even if it's only done once during the initial build)...? That could easily
>> sum up to a couple of hours for a fresh checkout of QEMU...
> 
> That's absolutely *NOT* what I was suggesting.
> 
> We should have a 'qemu-test-images.git' repository that maintains all
> the recipes, with CI jobs to build and publish them (along with corresponding
> source). Those prebuilt images would be consumed by QEMU functional tests.
> This would be quicker than what we have today, as the images downloaded by
> functional tests could be an order of magnitude smaller, and boot more
> quickly too.

Ah, sorry for getting that wrong!

Ok, so this sounds basically just like a gitlab-CI wrapper around what 
buildroot.org already provides. ... not sure whether that's challenging 
enough for a GSoC project?

Also, adding this as a separate repository will easily burn your gitlab-CI 
minutes if you don't have a dedicated runner for this, so developing this 
feature might be no fun at all...

  Thomas


  Thomas

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 12:05:14PM +0100, Thomas Huth wrote:
> On 22/01/2026 11.48, Daniel P. Berrangé wrote:
> > On Thu, Jan 22, 2026 at 11:43:35AM +0100, Thomas Huth wrote:
> > > On 22/01/2026 11.14, Daniel P. Berrangé wrote:
> > > > On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> > > > > Hi Marc-André,
> > > > > I haven't seen discussion about the project ideas you posted, so I'll
> > > > > try to kick it off here for the mkosi idea here.
> > > > > 
> > > > > Thomas: Would you like to co-mentor the following project with
> > > > > Marc-André? Also, do you have any concerns about the project idea from
> > > > > the maintainer perspective?
> > > 
> > > I'm fine with co-mentoring the project, but could you do me a favour and add
> > > some wording about AI tools to
> > > https://wiki.qemu.org/Google_Summer_of_Code_2026 to set the expectations
> > > right? Since we don't allow AI generated code in QEMU, I'd appreciate if we
> > > could state this in a prominent place here to avoid that some people think
> > > they could get some quick money here by using AI tools, just to finally
> > > discover that AI generated code is not allowed in the QEMU project. Thanks!
> > > 
> > > > IMHO, our baseline for functional testing images ought to be
> > > > a Linux Kconfig recipe used to build a dedicate kernel, plus
> > > > a busybox build for the target.
> > > 
> > > Not sure if we want to add kernel compilation time to the functional tests
> > > (even if it's only done once during the initial build)...? That could easily
> > > sum up to a couple of hours for a fresh checkout of QEMU...
> > 
> > That's absolutely *NOT* what I was suggesting.
> > 
> > We should have a 'qemu-test-images.git' repository that maintains all
> > the recipes, with CI jobs to build and publish them (along with corresponding
> > source). Those prebuilt images would be consumed by QEMU functional tests.
> > This would be quicker than what we have today, as the images downloaded by
> > functional tests could be an order of magnitude smaller, and boot more
> > quickly too.
> 
> Ah, sorry for getting that wrong!
> 
> Ok, so this sounds basically just like a gitlab-CI wrapper around what
> buildroot.org already provides. ... not sure whether that's challenging
> enough for a GSoC project?

Given the number of machines we have, it is certainly time consuming
enough to figure out the build for each one, and integrate it with
the functional test. Not massively mentally challenging, but that's
not a bad thing for GSoC.

> Also, adding this as a separate repository will easily burn your gitlab-CI
> minutes if you don't have a dedicated runner for this, so developing this
> feature might be no fun at all...

I'd expect most of the work would be on a local machine to construct and
test images for all the different machines and validate them in functional
tests. The integration into GitLab CI is a small-ish part which could be
validated with just a couple of images, so you'd only burn major CI credits
towards the end when needing to do a full run across all images.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Call for GSoC internship project ideas

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> On 22/01/2026 11.48, Daniel P. Berrangé wrote:
>> On Thu, Jan 22, 2026 at 11:43:35AM +0100, Thomas Huth wrote:
>>> On 22/01/2026 11.14, Daniel P. Berrangé wrote:
>>>> On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
>>>>> Hi Marc-André,
>>>>> I haven't seen discussion about the project ideas you posted, so I'll
>>>>> try to kick it off here for the mkosi idea here.
>>>>>
>>>>> Thomas: Would you like to co-mentor the following project with
>>>>> Marc-André? Also, do you have any concerns about the project idea from
>>>>> the maintainer perspective?
>>>
>>> I'm fine with co-mentoring the project, but could you do me a favour and add
>>> some wording about AI tools to
>>> https://wiki.qemu.org/Google_Summer_of_Code_2026 to set the expectations
>>> right? Since we don't allow AI generated code in QEMU, I'd appreciate if we
>>> could state this in a prominent place here to avoid that some people think
>>> they could get some quick money here by using AI tools, just to finally
>>> discover that AI generated code is not allowed in the QEMU project. Thanks!
>>>
>>>> IMHO, our baseline for functional testing images ought to be
>>>> a Linux Kconfig recipe used to build a dedicate kernel, plus
>>>> a busybox build for the target.
>>>
>>> Not sure if we want to add kernel compilation time to the functional tests
>>> (even if it's only done once during the initial build)...? That could easily
>>> sum up to a couple of hours for a fresh checkout of QEMU...
>> That's absolutely *NOT* what I was suggesting.
>> We should have a 'qemu-test-images.git' repository that maintains
>> all
>> the recipes, with CI jobs to build and publish them (along with corresponding
>> source). Those prebuilt images would be consumed by QEMU functional tests.
>> This would be quicker than what we have today, as the images downloaded by
>> functional tests could be an order of magnitude smaller, and boot more
>> quickly too.
>
> Ah, sorry for getting that wrong!
>
> Ok, so this sounds basically just like a gitlab-CI wrapper around what
> buildroot.org already provides. ... not sure whether that's
> challenging enough for a GSoC project?
>
> Also, adding this as a separate repository will easily burn your
> gitlab-CI minutes if you don't have a dedicated runner for this, so
> developing this feature might be no fun at all...

My intention was to get the test images as part of buildroots own
testing setup and re-use them for QEMU.

>
>  Thomas
>
>
>  Thomas

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Thu, Jan 22, 2026 at 5:43 AM Thomas Huth <thuth@redhat.com> wrote:
>
> On 22/01/2026 11.14, Daniel P. Berrangé wrote:
> > On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
> >> Hi Marc-André,
> >> I haven't seen discussion about the project ideas you posted, so I'll
> >> try to kick it off here for the mkosi idea here.
> >>
> >> Thomas: Would you like to co-mentor the following project with
> >> Marc-André? Also, do you have any concerns about the project idea from
> >> the maintainer perspective?
>
> I'm fine with co-mentoring the project, but could you do me a favour and add
> some wording about AI tools to
> https://wiki.qemu.org/Google_Summer_of_Code_2026 to set the expectations
> right? Since we don't allow AI generated code in QEMU, I'd appreciate if we
> could state this in a prominent place here to avoid that some people think
> they could get some quick money here by using AI tools, just to finally
> discover that AI generated code is not allowed in the QEMU project. Thanks!

Yes. As part of our GSoC application I am going to combine the 3
statements about AI that are currently spread throughout the wiki page
into a single section.

Stefan

Re: Call for GSoC internship project ideas

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote:
>> Hi Marc-André,
>> I haven't seen discussion about the project ideas you posted, so I'll
>> try to kick it off here for the mkosi idea here.
>> 
>> Thomas: Would you like to co-mentor the following project with
>> Marc-André? Also, do you have any concerns about the project idea from
>> the maintainer perspective?
>> 
>> === Reproducible Test Image Building with mkosi ===
>
>> This project proposes using mkosi to build minimal, reproducible test
>> images directly from distribution packages. mkosi is a tool for
>> building clean OS images from distribution packages, with excellent
>> support for Fedora and other distributions. It should be able to
>> produces deterministic outputs.
>
> Aside from what I mentioned already, the other issue I anticipate
> with mkosi is the mismatch between what hardware QEMU needs to be
> able to cover, vs what hardware the distros actually support.
>
> Fedora in particular is pretty narrow in its coverage. Debian is
> considerably broader.
>
> Neither will support all the QEMU targets, let alone all the
> machine types within the target.
>
>
> While there is value in testing a full blown OS image, IMHO,
> for most of what we need it is considerable overkill, and
> thus makes functional tests slower than they would otherwise
> need to be.
>
> IMHO, our baseline for functional testing images ought to be
> a Linux Kconfig recipe used to build a dedicate kernel, plus
> a busybox build for the target.
>
> This would let us create either a self contained initrd, or
> a tiny root disk, both of which would reliably boot in a
> barely more than a second or two, even under TCG.

This is why I've been building my iamges with buildroot. It provides for
a lean user-space with exactly what you want and it can create a
software BOM for the whole thing.

But it also allows me to bring in more complex things if I need to like
the vkmark tests for example.

> This would have a number of other benefits
>
>  * Not dependent on distros supporting the given QEMU
>    target and machine type. As long as a Linux port
>    exists and busybox compiles, we can test it
>  
>  * Identical test image functionality for every single
>    target and machine type. No hodge-podge of different
>    3rd party guest OS.
>
>  * Stable forever, with all changes entirely under
>    our own control. No distro changes that arbitrarily
>    break our CI.
>
>  * Easier to debug when it breaks, since there would
>    be a small well defined set of logic running in
>    the guest userspace
>
>  * Fairly easy for QEMU to provide the complete and
>    corresponding source for any binary images, since
>    we've built it all from scratch
>
>  * Tiny & fast downloads of pre-built images.
>
>
> This would not eliminate the need for testing real OS images,
> but would significantly downgrade their importance.
>
> Functional tests could be in three groups - 'quick', as today,
> 'slow' the smoke tests with our miny kernel+busybox, 'thorough'
> the full OS images.
>
>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC internship project ideas

[John Levon]

On Wed, Jan 14, 2026 at 02:26:48PM -0500, Stefan Hajnoczi wrote:

> I have some thoughts about the vfio-user project idea:

https://wiki.qemu.org/Internships/ProjectIdeas/VFIOUSER
> 
> > === First-Class vfio-user Device Support ===
> >
> > '''Summary:''' Promote QEMU's experimental vfio-user device support to production-ready status by adding comprehensive testing, documentation, migration support, and seamless CLI integration.
> >
> > Since 2022, QEMU has included `x-vfio-user-server` for running emulated PCI devices in standalone processes using the vfio-user protocol. This enables security isolation, modular device development, and flexible deployment architectures.
> >
> > However, adoption has been limited due to:
> > * '''Experimental status''' - All components use `x-` prefix indicating unstable API
> 
> This is a question of whether the command-line interface is stable.
> John Levon, Thanos Makatos, and Cédric Le Goater are the maintainers
> for vfio-user. I wonder what their thoughts on removing the "x-" are?

Just remembered I hadn't replied here in public. Actually, Jag and Elena are the
maintainers of the server portion of this, so would be interested in their
opinions.

As a maintainer of the client side, I think this is a great project, though, and
would love to see vfio-user-server brought back into a good working state and
the legacy protocol dropped! And we would be happy to support where we can.

> The vfio-user protocol has adopted the kernel VFIO interface's device
> state migration features. In theory the protocol supports migration,
> but I don't see QEMU code that implements the protocol features. If my
> understanding is correct, then there is a (sub-)project here to
> implement live migration protocol features in --device vfio-user-pci
> (the proxy) as well as in --object x-vfio-user-server (QEMU's server)?

Correct; we dropped all the live migration stuff as part of integrating. We have
protocol definitions and library server support for this. There is also somebody
who has some draft qemu patches around!

regards
john

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

Hi Markus and Marc-André,
Any thoughts on the Marc-André's HMP internship project idea?

Markus: Would you like to co-mentor this project with Marc-André?

=== External HMP Implementation via QMP ===

'''Summary:''' Implement a standalone HMP-compatible monitor as an
external binary (Python or Rust) that communicates with QEMU
exclusively through QMP, enabling future decoupling of the built-in
HMP from QEMU core.

QEMU provides two monitor interfaces:
* '''QMP''' (QEMU Machine Protocol): A JSON-based machine-readable
protocol for programmatic control
* '''HMP''' (Human Monitor Protocol): A text-based interactive
interface for human operators

Currently, HMP is tightly integrated into QEMU, with commands defined
in `hmp-commands.hx` and `hmp-commands-info.hx`. Most HMP commands
already delegate to QMP internally (e.g., `hmp_quit()` calls
`qmp_quit()`), but HMP parsing, formatting, and command dispatch are
compiled into the QEMU binary.

This project aims to externalize HMP functionality, providing a
standalone tool that offers the same user experience while
communicating with QEMU purely through QMP.

'''Add `CONFIG_HMP` build option''':
* Create a new Meson configuration option to disable built-in HMP
* Allow QEMU to be built without HMP
* Facilitate testing of external HMP as a replacement

'''Create an external HMP implementation''' in Python or Rust that:
* Connects to QEMU via QMP socket
* Parses HMP command syntax and translates to QMP calls
* Formats QMP responses as human-readable HMP output
* Supports command completion and help text

'''Use `hmp-commands.hx` for code generation''':
* Parse the existing `.hx` files to extract command definitions
* Generate boilerplate code (command tables, argument parsing, help text)
* Produce a report of implemented vs. unimplemented commands
* Enable tracking of HMP/QMP parity

'''Identify and address QMP gaps''':
* Audit all HMP commands for QMP equivalents
* For critical missing commands, propose QAPI schema additions
* Document commands that cannot be externalized
* Provide patches or RFCs for missing QMP functionality

'''Future Work''' (out of scope):

* Seamless replacement of built-in HMP

'''Links:'''
* https://wiki.qemu.org/Documentation/QMP - QMP documentation
* https://wiki.qemu.org/Features/QAPI - QAPI schema system
* https://www.qemu.org/docs/master/interop/qemu-qmp-ref.html - QMP reference
* https://www.qemu.org/docs/master/system/monitor.html - HMP documentation

'''Details:'''
* Skill level: intermediate
* Language: Python or Rust (student choice), with C for QMP gap patches
* Mentor: Marc-André Lureau <marcandre.lureau@redhat.com> (elmarco on IRC)
* Markus?
* Suggested by: Marc-André Lureau

Stefan

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

On Mon, Jan 05, 2026 at 04:47:22PM -0500, Stefan Hajnoczi wrote:
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> January 30th.
> 

Hello,

We came up with the following idea.

Thanks.

=== virtio-rtc vhost-user device ===

'''Summary:''' Implement virtio-rtc device as a vhost-device-user

Implement virtio-rtc device using the vhost-user-device framework.

The goal of this project is to implement a virtio-rtc device as a
vhost-user-device. At the moment, there is no open implementation of a
virtio-rtc device, even though a virtio-rtc driver exists and appears to
be tested against a closed device implementation. This project aims to
fill that gap by providing a fully open and spec-aligned device.

The virtio-rtc device provides access to real-time clocks, such as UTC
or TAI, or physical time elapsed since a given epoch. The driver can
read the time using simple or more accurate methods and may optionally
set an alarm.

The work starts with understanding the virtio-rtc device as described in
the virtio specification, as well as studying the existing virtio-rtc
driver. In parallel, an existing vhost-user-device implementation can be
used as a reference to design and write the new device. The device will
be implemented in Rust and must follow the virtio specification closely.

The project also includes debugging interoperability issues, identifying
possible mismatches between the driver and the specification, and
submitting the final implementation to the vhost-device project.

High-level tasks:
- Study the virtio-rtc specification and understand the existing
  virtio-rtc driver. Also, it may help study the QEMU implementation of
  the rtc clock.
- Design and implement the virtio-rtc device as a vhost-user-device in
  Rust. Existing vhost-user-devices may help to get inspiration. This
  step also requires adding the glue code in QEMU to support this
  device.
- Build and test the virtio-rtc driver.
- Test, debug, and submit the new device to the vhost-device project.

'''Links:'''
* Linux Driver Series:
  https://lore.kernel.org/all/20250509160734.1772-1-quic_philber@quicinc.com/
* vhost-device repo: https://github.com/rust-vmm/vhost-device
* VirtIO 1.4 specification:
  https://github.com/oasis-tcs/virtio-spec/tree/virtio-1.4/device-types/rtc

'''Details:'''
* Skill level: intermediate
* Language: C/Rust
* Mentors: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>,
  Francesco Valla <francesco@valla.it> and Stefano Garzarella
  <garzare@redhat.com>

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Tue, Jan 27, 2026 at 4:27 AM Matias Ezequiel Vara Larsen
<mvaralar@redhat.com> wrote:
>
> On Mon, Jan 05, 2026 at 04:47:22PM -0500, Stefan Hajnoczi wrote:
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship
> > program again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email by
> > January 30th.
> >
>
> Hello,
>
> We came up with the following idea.

Great project idea! I have edited it to get closer to the new 2-5
sentence recommendation and posted it here:
https://wiki.qemu.org/Google_Summer_of_Code_2026#virtio-rtc_vhost-user_device

I listed the project size as 175 or 350 hours. This will depend on the
intern's experience level. Someone familiar with Rust and who has done
their research on virtio-rtc could implement it more quickly. Someone
less experienced or investing more time in testing could spend more
time on the project.

Feel free to edit the project idea on the wiki.

Stefan