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

[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

[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

[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

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

[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

[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

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

[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

[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

[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

Modern HMP (was: Call for GSoC internship project ideas)

[Markus Armbruster]

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

> Hi
>
> On Tue, Jan 6, 2026 at 1:47 AM 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
>> January 30th.

[...]

>> How to propose your idea
>> ------------------------------
>> Reply to this email with the following project idea template filled in:
>>
>
> 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/ModernHMP

[...]

Let's start the discussion with your nicely written Wiki page:

    === 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.

Also line editing and completion.

Most HMP commands cleanly wrap around QMP command handlers such as
qmp_quit().  Wrapping them around QMP commands instead is a
straightforward problem.  I'm more concerned about HMP stuff that uses
other internal interfaces.  Replacing them may require new QMP
interfaces, or maybe a careful culling of inessential HMP features.
Known such stuff: completion does not wrap around QMP command handlers.
It is provided by the HMP core.

Risk: this can easily become the 10% that take the other 90% of the
time, or even the 5% that sink the project.

Risk: serious code duplication until we can get rid of built-in HMP.
Fine if the goal is to explore and learn by building a prototype, and we
simply throw away the prototype afterwards.

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

Potential for a better editing experience, because our readline
reimplementation is lacking compared to the real thing.

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

.hx is C source code with ReST snippets.  scripts/hxtool strips out the
ReST.  docs/sphinx/hxtool.py ignores the C source code, and processes
the ReST.  It works.  Not a fan.

If we succeed in replacing built-in HMP by an external one, and the
external one isn't written in C, then having C source code in .hx no
longer makes sense.  Parsing it will be wasted effort.  It may still
make sense initially.

    '''Identify and address QMP gaps''':
    * Audit all HMP commands for QMP equivalents

Also audit the HMP core.  Known problem: completion.

    * 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?

Makes sense.

    * Suggested by: Marc-André Lureau

Re: Modern HMP (was: Call for GSoC internship project ideas)

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 10:38:28AM +0100, Markus Armbruster wrote:
> Let's start the discussion with your nicely written Wiki page:
> 
>     === 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.

First of all, I love the idea. An external HMP impl that consumes
QMP from outside QEMU so a concept I've suggested many times over
10+ years hoping someone would take the bait and impl it :-)

> Also line editing and completion.
> 
> Most HMP commands cleanly wrap around QMP command handlers such as
> qmp_quit().  Wrapping them around QMP commands instead is a
> straightforward problem.  I'm more concerned about HMP stuff that uses
> other internal interfaces.  Replacing them may require new QMP
> interfaces, or maybe a careful culling of inessential HMP features.
> Known such stuff: completion does not wrap around QMP command handlers.
> It is provided by the HMP core.
> 
> Risk: this can easily become the 10% that take the other 90% of the
> time, or even the 5% that sink the project.

IMHO this is essentially guaranteed.

4 years ago I tried to move us closer to this world by introducing
"HumanReadableText" and documenting that all remaining & future
"info xxx" commands should be backed by a QMP command that just
returns human formatted text. The intent was to eliminate the
roadblock of having to define formal QAPI types for all the
complex data.

I converted a bunch of commands, but that indeed became do 90%
of the work, leave the other 90% of the work for later victim^H^H^H
contributor.

None of this means that the GSoc project idea is invalid. We just
have to figure out a credible end goal is for the project, ideally
with staged delivery.

> Risk: serious code duplication until we can get rid of built-in HMP.
> Fine if the goal is to explore and learn by building a prototype, and we
> simply throw away the prototype afterwards.

IMHO that isn't a risk, that's a guarantee. I can't imagine converting
all remaining HMP commands to have a QMP backing, AND doing an external
HMP impl all within the GSoc timeline.  That's two largely independent
projects, each of which are probably longer than the GSoC time wnidow.

Again that doesn't mean the idea is invalid for GSoc, just that we must
be honest about likely deliverables, and how follow up work will happen
after GSoc to maximise benefit for QEMU.

What I would not want to see is a bunch of work done that is then
abandoned because it couldn't get used as it wasn't feature complete.
Whatever subset is achieved ought to be intended as a stepping stone
we can integrate and carry on working with.


>     '''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
> 
> .hx is C source code with ReST snippets.  scripts/hxtool strips out the
> ReST.  docs/sphinx/hxtool.py ignores the C source code, and processes
> the ReST.  It works.  Not a fan.
> 
> If we succeed in replacing built-in HMP by an external one, and the
> external one isn't written in C, then having C source code in .hx no
> longer makes sense.  Parsing it will be wasted effort.  It may still
> make sense initially.

Indeed, we should clarify language intended as it would influence
the approach for the project.  If it is a clean room Rust impl,
then it would be completely independent of existing HMP C code.
More work initially to ensure we retain the same data formatting
of each command, but likely nicer long term, and saying Rust will
probably attract more candidates to the idea.


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

[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

[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 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

[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

[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

[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]

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

[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

[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: Modern HMP

[Markus Armbruster]

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

> On Thu, Jan 22, 2026 at 10:38:28AM +0100, Markus Armbruster wrote:
>> Let's start the discussion with your nicely written Wiki page:
>> 
>>     === 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.
>
> First of all, I love the idea. An external HMP impl that consumes
> QMP from outside QEMU so a concept I've suggested many times over
> 10+ years hoping someone would take the bait and impl it :-)
>
>> Also line editing and completion.
>> 
>> Most HMP commands cleanly wrap around QMP command handlers such as
>> qmp_quit().  Wrapping them around QMP commands instead is a
>> straightforward problem.  I'm more concerned about HMP stuff that uses
>> other internal interfaces.  Replacing them may require new QMP
>> interfaces, or maybe a careful culling of inessential HMP features.
>> Known such stuff: completion does not wrap around QMP command handlers.
>> It is provided by the HMP core.
>> 
>> Risk: this can easily become the 10% that take the other 90% of the
>> time, or even the 5% that sink the project.
>
> IMHO this is essentially guaranteed.
>
> 4 years ago I tried to move us closer to this world by introducing
> "HumanReadableText" and documenting that all remaining & future
> "info xxx" commands should be backed by a QMP command that just
> returns human formatted text. The intent was to eliminate the
> roadblock of having to define formal QAPI types for all the
> complex data.
>
> I converted a bunch of commands, but that indeed became do 90%
> of the work, leave the other 90% of the work for later victim^H^H^H
> contributor.
>
> None of this means that the GSoc project idea is invalid. We just
> have to figure out a credible end goal is for the project, ideally
> with staged delivery.

Makes sense.

If we see the GSoC project as a first step towards replacing the
built-in HMP by an standalone program talking QMP ("Modern HMP"), we
better scope it carefully, so it (1) has achievable success criteria,
and (2) makes real progress towards the actual finish line.

>> Risk: serious code duplication until we can get rid of built-in HMP.
>> Fine if the goal is to explore and learn by building a prototype, and we
>> simply throw away the prototype afterwards.
>
> IMHO that isn't a risk, that's a guarantee. I can't imagine converting
> all remaining HMP commands to have a QMP backing, AND doing an external
> HMP impl all within the GSoc timeline.  That's two largely independent
> projects, each of which are probably longer than the GSoC time wnidow.
>
> Again that doesn't mean the idea is invalid for GSoc, just that we must
> be honest about likely deliverables, and how follow up work will happen
> after GSoc to maximise benefit for QEMU.
>
> What I would not want to see is a bunch of work done that is then
> abandoned because it couldn't get used as it wasn't feature complete.
> Whatever subset is achieved ought to be intended as a stepping stone
> we can integrate and carry on working with.

Does the GSoC project make sense without a firm commitment to followup
work to finish the job?

Specifically, commitment by whom to do what?

>>     '''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
>> 
>> .hx is C source code with ReST snippets.  scripts/hxtool strips out the
>> ReST.  docs/sphinx/hxtool.py ignores the C source code, and processes
>> the ReST.  It works.  Not a fan.
>> 
>> If we succeed in replacing built-in HMP by an external one, and the
>> external one isn't written in C, then having C source code in .hx no
>> longer makes sense.  Parsing it will be wasted effort.  It may still
>> make sense initially.
>
> Indeed, we should clarify language intended as it would influence
> the approach for the project.  If it is a clean room Rust impl,
> then it would be completely independent of existing HMP C code.
> More work initially to ensure we retain the same data formatting
> of each command, but likely nicer long term, and saying Rust will
> probably attract more candidates to the idea.

In theory, we could make the same HMP code work in both contexts,
built-in HMP and standaline HMP.  I doubt this is feasible, at least not
at reasonable cost.  Too much disentangling.  I could be wrong.

If we use separate HMP code, i.e. accept code duplication until we
retire built-in HMP, then picking a different language for the new copy
won't add all that much to the bother of having to maintain two copies.

HMP is not a stable interface.  We make reasonable efforts not to change
the output without a good reason.  I don't think identical data
formatting is a requirement.  Just make a reasonable effort.

Marc-André proposed Python or Rust.  Anyone got a preference backed by
reasons?

Re: Modern HMP

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 01:07:43PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Thu, Jan 22, 2026 at 10:38:28AM +0100, Markus Armbruster wrote:
> >> Let's start the discussion with your nicely written Wiki page:
> >> 
> >>     === 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.
> >
> > First of all, I love the idea. An external HMP impl that consumes
> > QMP from outside QEMU so a concept I've suggested many times over
> > 10+ years hoping someone would take the bait and impl it :-)
> >
> >> Also line editing and completion.
> >> 
> >> Most HMP commands cleanly wrap around QMP command handlers such as
> >> qmp_quit().  Wrapping them around QMP commands instead is a
> >> straightforward problem.  I'm more concerned about HMP stuff that uses
> >> other internal interfaces.  Replacing them may require new QMP
> >> interfaces, or maybe a careful culling of inessential HMP features.
> >> Known such stuff: completion does not wrap around QMP command handlers.
> >> It is provided by the HMP core.
> >> 
> >> Risk: this can easily become the 10% that take the other 90% of the
> >> time, or even the 5% that sink the project.
> >
> > IMHO this is essentially guaranteed.
> >
> > 4 years ago I tried to move us closer to this world by introducing
> > "HumanReadableText" and documenting that all remaining & future
> > "info xxx" commands should be backed by a QMP command that just
> > returns human formatted text. The intent was to eliminate the
> > roadblock of having to define formal QAPI types for all the
> > complex data.
> >
> > I converted a bunch of commands, but that indeed became do 90%
> > of the work, leave the other 90% of the work for later victim^H^H^H
> > contributor.
> >
> > None of this means that the GSoc project idea is invalid. We just
> > have to figure out a credible end goal is for the project, ideally
> > with staged delivery.
> 
> Makes sense.
> 
> If we see the GSoC project as a first step towards replacing the
> built-in HMP by an standalone program talking QMP ("Modern HMP"), we
> better scope it carefully, so it (1) has achievable success criteria,
> and (2) makes real progress towards the actual finish line.
> 
> >> Risk: serious code duplication until we can get rid of built-in HMP.
> >> Fine if the goal is to explore and learn by building a prototype, and we
> >> simply throw away the prototype afterwards.
> >
> > IMHO that isn't a risk, that's a guarantee. I can't imagine converting
> > all remaining HMP commands to have a QMP backing, AND doing an external
> > HMP impl all within the GSoc timeline.  That's two largely independent
> > projects, each of which are probably longer than the GSoC time wnidow.
> >
> > Again that doesn't mean the idea is invalid for GSoc, just that we must
> > be honest about likely deliverables, and how follow up work will happen
> > after GSoc to maximise benefit for QEMU.
> >
> > What I would not want to see is a bunch of work done that is then
> > abandoned because it couldn't get used as it wasn't feature complete.
> > Whatever subset is achieved ought to be intended as a stepping stone
> > we can integrate and carry on working with.
> 
> Does the GSoC project make sense without a firm commitment to followup
> work to finish the job?
> 
> Specifically, commitment by whom to do what?
> 
> >>     '''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
> >> 
> >> .hx is C source code with ReST snippets.  scripts/hxtool strips out the
> >> ReST.  docs/sphinx/hxtool.py ignores the C source code, and processes
> >> the ReST.  It works.  Not a fan.
> >> 
> >> If we succeed in replacing built-in HMP by an external one, and the
> >> external one isn't written in C, then having C source code in .hx no
> >> longer makes sense.  Parsing it will be wasted effort.  It may still
> >> make sense initially.
> >
> > Indeed, we should clarify language intended as it would influence
> > the approach for the project.  If it is a clean room Rust impl,
> > then it would be completely independent of existing HMP C code.
> > More work initially to ensure we retain the same data formatting
> > of each command, but likely nicer long term, and saying Rust will
> > probably attract more candidates to the idea.
> 
> In theory, we could make the same HMP code work in both contexts,
> built-in HMP and standaline HMP.  I doubt this is feasible, at least not
> at reasonable cost.  Too much disentangling.  I could be wrong.
> 
> If we use separate HMP code, i.e. accept code duplication until we
> retire built-in HMP, then picking a different language for the new copy
> won't add all that much to the bother of having to maintain two copies.
> 
> HMP is not a stable interface.  We make reasonable efforts not to change
> the output without a good reason.  I don't think identical data
> formatting is a requirement.  Just make a reasonable effort.
> 
> Marc-André proposed Python or Rust.  Anyone got a preference backed by
> reasons?

My suggestion would be Rust, as it allows the possibility to embed
that Rust impl inside the current QEMU binaries, to fully replace
the C code and retain broadly the same functionality.

We might never do it, but it feels like a good idea to keep the
door option.  Python rules that out entirely meaning we keep the
current C code forever, unless we do a full break with command
line compatibility at some point.

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: Modern HMP

[Markus Armbruster]

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

> On Thu, Jan 22, 2026 at 01:07:43PM +0100, Markus Armbruster wrote:

[...]

>> Marc-André proposed Python or Rust.  Anyone got a preference backed by
>> reasons?
>
> My suggestion would be Rust, as it allows the possibility to embed
> that Rust impl inside the current QEMU binaries, to fully replace
> the C code and retain broadly the same functionality.
>
> We might never do it, but it feels like a good idea to keep the
> door option.  Python rules that out entirely meaning we keep the
> current C code forever, unless we do a full break with command
> line compatibility at some point.

qemu-system-FOO could conceivably spawn the standalone HMP program
connected to a dedicated QMP monitor.

Re: Modern HMP

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 02:07:52PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Thu, Jan 22, 2026 at 01:07:43PM +0100, Markus Armbruster wrote:
> 
> [...]
> 
> >> Marc-André proposed Python or Rust.  Anyone got a preference backed by
> >> reasons?
> >
> > My suggestion would be Rust, as it allows the possibility to embed
> > that Rust impl inside the current QEMU binaries, to fully replace
> > the C code and retain broadly the same functionality.
> >
> > We might never do it, but it feels like a good idea to keep the
> > door option.  Python rules that out entirely meaning we keep the
> > current C code forever, unless we do a full break with command
> > line compatibility at some point.
> 
> qemu-system-FOO could conceivably spawn the standalone HMP program
> connected to a dedicated QMP monitor.

Certainly a technical option, but I would consider it undesirable
to impose the python runtime on all current usage of QEMU that wants
HMP.

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

[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: Modern HMP

[Fabiano Rosas]

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

> On Thu, Jan 22, 2026 at 01:07:43PM +0100, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > On Thu, Jan 22, 2026 at 10:38:28AM +0100, Markus Armbruster wrote:
>> >> Let's start the discussion with your nicely written Wiki page:
>> >> 
>> >>     === 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.
>> >
>> > First of all, I love the idea. An external HMP impl that consumes
>> > QMP from outside QEMU so a concept I've suggested many times over
>> > 10+ years hoping someone would take the bait and impl it :-)
>> >
>> >> Also line editing and completion.
>> >> 
>> >> Most HMP commands cleanly wrap around QMP command handlers such as
>> >> qmp_quit().  Wrapping them around QMP commands instead is a
>> >> straightforward problem.  I'm more concerned about HMP stuff that uses
>> >> other internal interfaces.  Replacing them may require new QMP
>> >> interfaces, or maybe a careful culling of inessential HMP features.
>> >> Known such stuff: completion does not wrap around QMP command handlers.
>> >> It is provided by the HMP core.
>> >> 
>> >> Risk: this can easily become the 10% that take the other 90% of the
>> >> time, or even the 5% that sink the project.
>> >
>> > IMHO this is essentially guaranteed.
>> >
>> > 4 years ago I tried to move us closer to this world by introducing
>> > "HumanReadableText" and documenting that all remaining & future
>> > "info xxx" commands should be backed by a QMP command that just
>> > returns human formatted text. The intent was to eliminate the
>> > roadblock of having to define formal QAPI types for all the
>> > complex data.
>> >
>> > I converted a bunch of commands, but that indeed became do 90%
>> > of the work, leave the other 90% of the work for later victim^H^H^H
>> > contributor.
>> >
>> > None of this means that the GSoc project idea is invalid. We just
>> > have to figure out a credible end goal is for the project, ideally
>> > with staged delivery.
>> 
>> Makes sense.
>> 
>> If we see the GSoC project as a first step towards replacing the
>> built-in HMP by an standalone program talking QMP ("Modern HMP"), we
>> better scope it carefully, so it (1) has achievable success criteria,
>> and (2) makes real progress towards the actual finish line.
>> 
>> >> Risk: serious code duplication until we can get rid of built-in HMP.
>> >> Fine if the goal is to explore and learn by building a prototype, and we
>> >> simply throw away the prototype afterwards.
>> >
>> > IMHO that isn't a risk, that's a guarantee. I can't imagine converting
>> > all remaining HMP commands to have a QMP backing, AND doing an external
>> > HMP impl all within the GSoc timeline.  That's two largely independent
>> > projects, each of which are probably longer than the GSoC time wnidow.
>> >
>> > Again that doesn't mean the idea is invalid for GSoc, just that we must
>> > be honest about likely deliverables, and how follow up work will happen
>> > after GSoc to maximise benefit for QEMU.
>> >
>> > What I would not want to see is a bunch of work done that is then
>> > abandoned because it couldn't get used as it wasn't feature complete.
>> > Whatever subset is achieved ought to be intended as a stepping stone
>> > we can integrate and carry on working with.
>> 
>> Does the GSoC project make sense without a firm commitment to followup
>> work to finish the job?
>> 
>> Specifically, commitment by whom to do what?
>> 
>> >>     '''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
>> >> 
>> >> .hx is C source code with ReST snippets.  scripts/hxtool strips out the
>> >> ReST.  docs/sphinx/hxtool.py ignores the C source code, and processes
>> >> the ReST.  It works.  Not a fan.
>> >> 
>> >> If we succeed in replacing built-in HMP by an external one, and the
>> >> external one isn't written in C, then having C source code in .hx no
>> >> longer makes sense.  Parsing it will be wasted effort.  It may still
>> >> make sense initially.
>> >
>> > Indeed, we should clarify language intended as it would influence
>> > the approach for the project.  If it is a clean room Rust impl,
>> > then it would be completely independent of existing HMP C code.
>> > More work initially to ensure we retain the same data formatting
>> > of each command, but likely nicer long term, and saying Rust will
>> > probably attract more candidates to the idea.
>> 
>> In theory, we could make the same HMP code work in both contexts,
>> built-in HMP and standaline HMP.  I doubt this is feasible, at least not
>> at reasonable cost.  Too much disentangling.  I could be wrong.
>> 
>> If we use separate HMP code, i.e. accept code duplication until we
>> retire built-in HMP, then picking a different language for the new copy
>> won't add all that much to the bother of having to maintain two copies.
>> 
>> HMP is not a stable interface.  We make reasonable efforts not to change
>> the output without a good reason.  I don't think identical data
>> formatting is a requirement.  Just make a reasonable effort.
>> 
>> Marc-André proposed Python or Rust.  Anyone got a preference backed by
>> reasons?
>
> My suggestion would be Rust, as it allows the possibility to embed
> that Rust impl inside the current QEMU binaries, to fully replace
> the C code and retain broadly the same functionality.
>

One question I have is what exactly gets (eventually) removed from QEMU
and what benefits we expect from it. Is it the entire "manual"
interaction that's undesirable? Or just that to maintain HMP there is a
certain amount of duplication? Or even the less-than-perfect
readline/completion aspects?

Does the new program becomes basically an external project unrelated to
QEMU, that simply talks to QMP like libvirt does?

I wonder how close to tools like qmp-shell, qmp-tui, etc that would
become and whether we might actually be looking at a substitute of
qemu.qmp.

Re: Modern HMP

[Daniel P. Berrangé]

On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote:
> One question I have is what exactly gets (eventually) removed from QEMU
> and what benefits we expect from it. Is it the entire "manual"
> interaction that's undesirable? Or just that to maintain HMP there is a
> certain amount of duplication? Or even the less-than-perfect
> readline/completion aspects?

Over time we've been gradually separating our human targetted code from
our machine targetted code, whether that's command line argument parsing,
or monitor parsing. Maintaining two ways todo the same thing is always
going to be a maint burden, and in QEMU it has been especially burdensome
as they were parallel impls in many cases, rather than one being exclusively
built on top of the other.

Even today we still get contributors sending patches which only impl
HMP code and not QMP code. Separating HMP fully from QMP so that it
was mandatory to create QMP first gets contributors going down the
right path, and should reduce the burden on maint.

At some point we are likely to introduce a new non-backwards compatible
QEMU binary. Perhaps when Philippe completes his "all targets/machines
in one binary" work. That would be an opportunity to carve HMP off
into a separate out of process facade talking over QMP.

That's only possible though if we get existing HMP into being a layer
over QMP with no backdoor parallel impls. So anything we can do today
to better separate QMP/HMP will give us more flexibility when the time
arrives to create a new QEMU binary without backwards compat cruft.

NB, introducing a new binary does not imply that the old binaries
go away. They would probably stick around for legacy compat for a
good while. For anything using libvirt though, we would be able to
switch to the new binaries pretty fast without, as libvirt can
translate app XML config to either the new or old QEMU dynamically.

> Does the new program becomes basically an external project unrelated to
> QEMU, that simply talks to QMP like libvirt does?

It could be a separate project under QEMU on github, or it could just be
binary in qemu.git. What matters is that it is out of the main QEMU process
eventually.

> I wonder how close to tools like qmp-shell, qmp-tui, etc that would
> become and whether we might actually be looking at a substitute of
> qemu.qmp.

qmp-shell is rather too crude in terms of its data input/output - have
to switch to JSON way too much, and there's no mechanism for formatting
complex QMP replies into pretty human friendly data.

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

[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

[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

[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: Modern HMP

[Kevin Wolf]

Am 22.01.2026 um 17:00 hat Daniel P. Berrangé geschrieben:
> > Does the new program becomes basically an external project unrelated to
> > QEMU, that simply talks to QMP like libvirt does?
> 
> It could be a separate project under QEMU on github, or it could just be
> binary in qemu.git. What matters is that it is out of the main QEMU process
> eventually.

I think the basic requirement for any HMP replacement is that it just
works, i.e. no manual setting up of sockets etc. like for qmp-shell.

If it's an external process, QEMU should just launch it automatically,
and the user interface should still go through the usual chardevs so
that the current backends still work and the default of '-monitor vc'
can be retained.

(Of course, once this plumbing has been done, it could be reused for
qmp-shell to provide a nicer and more integrated option there, too.)

This pretty much means that it has to be in the same project, or at
least a subproject that is automatically downloaded when building QEMU.

Kevin

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

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

COCONUT-SVSM project ideas for GSoC 2026

[Jörg Rödel]

Hi Stefan,

Thanks a lot for running this and allowing the COCONUT-SVSM project to submit
ideas under the QEMU/KVM umbrella!

After some discussions in the community we came up with these two project ideas:

=== Observability Support for COCONUT-SVSM ===

'''Summary:''' Implement Support for COCONUT-SVSM Observability within the TEE

COCONUT-SVSM is a Secure Virtual machine Service Module that runs at a
privileged level within a Confidential Virtual Machine (CVM) to provide trusted
services, such as a virtual TPM, to the guest operating system, independent of
the host hypervisor.

The goal of the project is to implement support for observability of
COCONUT-SVSM from the guest OS. When finished the guest OS has a way to
fetch runtime metrics and data from the COCONUT-SVSM running within the same
TEE. Runtime data includes the log buffer, services logs, memory usage, and
possible future extensions.

The project consists of several parts:

1. Design an experimental SVSM observability protocol for exchanging metrics
   and data between COCONUT-SVSM and the Linux kernel. This protocol will be an
   extension of the SVSM protocol specification.
2. Implement a handler for the protocol within COCONUT-SVSM following the other
   protocols COCONUT-SVSM already implements.
3. Implement a Linux device driver which uses this protocol to get
   observability data from COCONUT-SVSM and make it accessible to Linux user-mode
   via a device file.
4. Implement a Linux user-space utility to fetch and save the observability
   data using the device driver.

'''Links:'''

* COCONUT-SVSM Repository: https://github.com/coconut-svsm/svsm/
* Development plan: https://coconut-svsm.github.io/svsm/developer/DEVELOPMENT-PLAN/#observability
* SVSM protocol specification: https://docs.amd.com/v/u/en-US/58019

'''Details:'''
Skill level: Intermediate
Language: Rust and C
Mentors: Stefano Garzarella <sgarzare@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Joerg Roedel <joerg.roedel@amd.com>

--->8---

=== Support X86 Process Context Identifiers (PCID) in COCONUT-SVSM ===

COCONUT-SVSM is a Secure Virtual machine Service Module that runs at a
privileged level within a Confidential Virtual Machine (CVM) to provide trusted
services, such as a virtual TPM, to the guest operating system, independent of
the host hypervisor.

The goal of the project is to enhance the COCONUT-SVSM kernel to make use of
the PCID feature on X86 to reduce the number of runtime TLB misses. The work
consists of several steps:

1. Implement generic CPUID feature enumeration support by building a code
   generator which automatically creates a Rust crate from the data provided by
   the X86-CPUID project. Use that generated crate in COCONUT-SVSM for
   detecting the PCID feature and clean up all the open coded CPUID checks.
2. Design and implement a PCID assignment strategy for tasks and threads in the
   COCONUT kernel.
3. Apply the PCIDs in the COCONUT page-tables and adapt the TLB flushing code
   to take PCIDs into account.

'''Links:'''
* AMD64 APM 2 (PCIDs, Section 5.5.1.): https://docs.amd.com/v/u/en-US/24593_3.43 
* X86 cpuid project: https://x86-cpuid.org/
* COCONUT-SVSM: https://github.com/coconut-svsm/svsm/

'''Details:'''
* Skill level: Intermediate
* Languages: Rust
* Mentors: Joerg Roedel <joerg.roedel@amd.com>, Luigi Leonardi <leonardi@redhat.com>

--->8---

Thanks,

	Joerg

Re: COCONUT-SVSM project ideas for GSoC 2026

[Stefan Hajnoczi]

On Thu, Jan 29, 2026 at 5:46 AM Jörg Rödel <joro@8bytes.org> wrote:
>
> Hi Stefan,
>
> Thanks a lot for running this and allowing the COCONUT-SVSM project to submit
> ideas under the QEMU/KVM umbrella!
>

Welcome!

> After some discussions in the community we came up with these two project ideas:
>
> === Observability Support for COCONUT-SVSM ===
>
> '''Summary:''' Implement Support for COCONUT-SVSM Observability within the TEE
>
> COCONUT-SVSM is a Secure Virtual machine Service Module that runs at a
> privileged level within a Confidential Virtual Machine (CVM) to provide trusted
> services, such as a virtual TPM, to the guest operating system, independent of
> the host hypervisor.
>
> The goal of the project is to implement support for observability of
> COCONUT-SVSM from the guest OS. When finished the guest OS has a way to
> fetch runtime metrics and data from the COCONUT-SVSM running within the same
> TEE. Runtime data includes the log buffer, services logs, memory usage, and
> possible future extensions.
>
> The project consists of several parts:
>
> 1. Design an experimental SVSM observability protocol for exchanging metrics
>    and data between COCONUT-SVSM and the Linux kernel. This protocol will be an
>    extension of the SVSM protocol specification.

Interns have 12 weeks for the project. Usually this does not leave
enough time for the intern to propose a design and reach consensus
with the community. Keep in mind they may not have much background in
COCONUT-SVSM, so it will be challenging for them to come up with a
design.

I think the mentors should provide the extension to the SVSM protocol
specification. That way the intern can start the coding period by
diving straight into the implementation and there is no risk that the
project is held up because the community does not like the design.

> 2. Implement a handler for the protocol within COCONUT-SVSM following the other
>    protocols COCONUT-SVSM already implements.
> 3. Implement a Linux device driver which uses this protocol to get
>    observability data from COCONUT-SVSM and make it accessible to Linux user-mode
>    via a device file.
> 4. Implement a Linux user-space utility to fetch and save the observability
>    data using the device driver.

2, 3, and 4 together are a significant amount of work. I think it
would help to provide more details on what the interfaces look like.
Sketch out the command-line interface for the Linux user-space
utility, a Linux chardev (ioctl?) or sysfs interface that you would
like to see, etc. These details should probably go in the development
plan linked below on the COCONUT-SVSM website.

>
> '''Links:'''
>
> * COCONUT-SVSM Repository: https://github.com/coconut-svsm/svsm/
> * Development plan: https://coconut-svsm.github.io/svsm/developer/DEVELOPMENT-PLAN/#observability
> * SVSM protocol specification: https://docs.amd.com/v/u/en-US/58019
>
> '''Details:'''
> Skill level: Intermediate
> Language: Rust and C
> Mentors: Stefano Garzarella <sgarzare@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Joerg Roedel <joerg.roedel@amd.com>

Nice project idea. It's large but incremental, so even if the intern
doesn't complete everything, it will be possible to merge the finished
parts.

>
> --->8---
>
> === Support X86 Process Context Identifiers (PCID) in COCONUT-SVSM ===
>
> COCONUT-SVSM is a Secure Virtual machine Service Module that runs at a
> privileged level within a Confidential Virtual Machine (CVM) to provide trusted
> services, such as a virtual TPM, to the guest operating system, independent of
> the host hypervisor.
>
> The goal of the project is to enhance the COCONUT-SVSM kernel to make use of
> the PCID feature on X86 to reduce the number of runtime TLB misses. The work
> consists of several steps:
>
> 1. Implement generic CPUID feature enumeration support by building a code
>    generator which automatically creates a Rust crate from the data provided by
>    the X86-CPUID project. Use that generated crate in COCONUT-SVSM for
>    detecting the PCID feature and clean up all the open coded CPUID checks.
> 2. Design and implement a PCID assignment strategy for tasks and threads in the
>    COCONUT kernel.
> 3. Apply the PCIDs in the COCONUT page-tables and adapt the TLB flushing code
>    to take PCIDs into account.
>
> '''Links:'''
> * AMD64 APM 2 (PCIDs, Section 5.5.1.): https://docs.amd.com/v/u/en-US/24593_3.43
> * X86 cpuid project: https://x86-cpuid.org/
> * COCONUT-SVSM: https://github.com/coconut-svsm/svsm/
>
> '''Details:'''
> * Skill level: Intermediate
> * Languages: Rust
> * Mentors: Joerg Roedel <joerg.roedel@amd.com>, Luigi Leonardi <leonardi@redhat.com>

I have added this one to the wiki. Thank you!

https://wiki.qemu.org/Google_Summer_of_Code_2026#Support_X86_Process_Context_Identifiers_(PCID)_in_COCONUT-SVSM

Stefan

Re: Modern HMP

[Dr. David Alan Gilbert]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote:
> > One question I have is what exactly gets (eventually) removed from QEMU
> > and what benefits we expect from it. Is it the entire "manual"
> > interaction that's undesirable? Or just that to maintain HMP there is a
> > certain amount of duplication? Or even the less-than-perfect
> > readline/completion aspects?
> 
> Over time we've been gradually separating our human targetted code from
> our machine targetted code, whether that's command line argument parsing,
> or monitor parsing. Maintaining two ways todo the same thing is always
> going to be a maint burden, and in QEMU it has been especially burdensome
> as they were parallel impls in many cases, rather than one being exclusively
> built on top of the other.
> 
> Even today we still get contributors sending patches which only impl
> HMP code and not QMP code. Separating HMP fully from QMP so that it
> was mandatory to create QMP first gets contributors going down the
> right path, and should reduce the burden on maint.

Having a separate HMP isn't a bad idea - but it does need some idea of
how to make it easy for contributors to add stuff that's just for debug
or for the dev.   For HMP the bar is very low; if it's useful to the
dev, why not (unless it's copying something that's already in the QMP interface
in a different way);  but although the x- stuff in theory lets
you add something via QMP, in practice it's quite hard to get it through
review without a lot of QMP design bikeshedding.

Dave

-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Modern HMP

[Markus Armbruster]

"Dr. David Alan Gilbert" <dave@treblig.org> writes:

> * Daniel P. Berrangé (berrange@redhat.com) wrote:
>> On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote:
>> > One question I have is what exactly gets (eventually) removed from QEMU
>> > and what benefits we expect from it. Is it the entire "manual"
>> > interaction that's undesirable? Or just that to maintain HMP there is a
>> > certain amount of duplication? Or even the less-than-perfect
>> > readline/completion aspects?
>> 
>> Over time we've been gradually separating our human targetted code from
>> our machine targetted code, whether that's command line argument parsing,
>> or monitor parsing. Maintaining two ways todo the same thing is always
>> going to be a maint burden, and in QEMU it has been especially burdensome
>> as they were parallel impls in many cases, rather than one being exclusively
>> built on top of the other.
>> 
>> Even today we still get contributors sending patches which only impl
>> HMP code and not QMP code. Separating HMP fully from QMP so that it
>> was mandatory to create QMP first gets contributors going down the
>> right path, and should reduce the burden on maint.
>
> Having a separate HMP isn't a bad idea - but it does need some idea of
> how to make it easy for contributors to add stuff that's just for debug
> or for the dev.   For HMP the bar is very low; if it's useful to the
> dev, why not (unless it's copying something that's already in the QMP interface
> in a different way);  but although the x- stuff in theory lets
> you add something via QMP, in practice it's quite hard to get it through
> review without a lot of QMP design bikeshedding.

I think this description has become less accurate than it used to be :)

A long time ago, we started with "QMP is a stable, structured interface
for machines, HMP is a plain text interface for humans, and layered on
top of QMP."  Layered on top means HMP commands wrap around QMP
commands.  Ensures that QMP is obviously complete.  Without such a
layering, we'd have to verify completeness by inspection.  Impractical
given the size and complexity of the interfaces involved.

Trouble is there are things in HMP that make no sense in QMP.  For
instance, HMP command 'cpu' sets the monitor's default CPU, which
certain HMP commands use.  To wrap 'cpu' around a QMP command, we'd have
to drag the concept "default CPU" into QMP where it's not wanted.

So we retreated from "all", and permitted exceptions for commands that
make no sense in QMP.

We then found out the hard & expensive way that designing a QMP command
with its stable, structured interface is often a lot harder than
cobbling together an HMP command.  It's not just avoidable social
problems ("bikeshedding"); designing stable interfaces is just hard.
Sometimes the extra effort is worthwhile.  Sometimes it's not, e.g. when
all we really want is print something to aid a human with debugging.

So we retreated from "all" some more, and permitted exceptions for
commands meant exclusively for human use, typically debugging and
development aids.

This effectifely redefined the meaning of "complete": instead of "QMP
can do everything HMP can do and more", it's now "... except for certain
development and debugging aids and maybe other stuff".

To keep "maybe other stuff" under control, we required (and still
require) an *argument* for adding functionality just to HMP.

This turned out to be differently bothersome.  Having to review HMP
changes for QMP bypasses is bothersome, and bound to miss things at
least occasionally.  Having to ask for an argument is bothersome.
Constructing one is bothersome.

To reduce the bother, we retreated from another QMP ideal: the
structured interface.  Permit QMP commands to return just text when the
command is meant just for humans.  Such commands must be unstable.
Possible because we had retreated from "all of QMP is stable" meanwhile.

How does this work?  Instead of adding an HMP-only command, add a QMP
command that returns QAPI type HumanReadableText, and a trivial HMP
command that wraps around it.  Slightly more work, but no interface
design.

The QMP command addition is much more visible to the QAPI/QMP
maintainers than an HMP-only command would be.  This helps avoid missing
things.

We still want an argument why a structured interface isn't needed.  But
we can be much more lenient there: if it turns out to be needed, we can
just add it, and drop the unstructured interface.  Remember, it's
unstable.

Hope this helps.

Re: Modern HMP

[Daniel P. Berrangé]

On Wed, Feb 04, 2026 at 09:08:49AM +0100, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" <dave@treblig.org> writes:
> 
> > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> >> On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote:
> >> > One question I have is what exactly gets (eventually) removed from QEMU
> >> > and what benefits we expect from it. Is it the entire "manual"
> >> > interaction that's undesirable? Or just that to maintain HMP there is a
> >> > certain amount of duplication? Or even the less-than-perfect
> >> > readline/completion aspects?
> >> 
> >> Over time we've been gradually separating our human targetted code from
> >> our machine targetted code, whether that's command line argument parsing,
> >> or monitor parsing. Maintaining two ways todo the same thing is always
> >> going to be a maint burden, and in QEMU it has been especially burdensome
> >> as they were parallel impls in many cases, rather than one being exclusively
> >> built on top of the other.
> >> 
> >> Even today we still get contributors sending patches which only impl
> >> HMP code and not QMP code. Separating HMP fully from QMP so that it
> >> was mandatory to create QMP first gets contributors going down the
> >> right path, and should reduce the burden on maint.
> >
> > Having a separate HMP isn't a bad idea - but it does need some idea of
> > how to make it easy for contributors to add stuff that's just for debug
> > or for the dev.   For HMP the bar is very low; if it's useful to the
> > dev, why not (unless it's copying something that's already in the QMP interface
> > in a different way);  but although the x- stuff in theory lets
> > you add something via QMP, in practice it's quite hard to get it through
> > review without a lot of QMP design bikeshedding.
> 
> I think this description has become less accurate than it used to be :)
> 
> A long time ago, we started with "QMP is a stable, structured interface
> for machines, HMP is a plain text interface for humans, and layered on
> top of QMP."  Layered on top means HMP commands wrap around QMP
> commands.  Ensures that QMP is obviously complete.  Without such a
> layering, we'd have to verify completeness by inspection.  Impractical
> given the size and complexity of the interfaces involved.
> 
> Trouble is there are things in HMP that make no sense in QMP.  For
> instance, HMP command 'cpu' sets the monitor's default CPU, which
> certain HMP commands use.  To wrap 'cpu' around a QMP command, we'd have
> to drag the concept "default CPU" into QMP where it's not wanted.

Surely the isolated HMP monitor code can just keep track of its view
of a "default" CPU, and then pass an explicit CPU to the QMP commands
it runs ?


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: Modern HMP

[Markus Armbruster]

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

> On Wed, Feb 04, 2026 at 09:08:49AM +0100, Markus Armbruster wrote:
>> "Dr. David Alan Gilbert" <dave@treblig.org> writes:
>> 
>> > * Daniel P. Berrangé (berrange@redhat.com) wrote:
>> >> On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote:
>> >> > One question I have is what exactly gets (eventually) removed from QEMU
>> >> > and what benefits we expect from it. Is it the entire "manual"
>> >> > interaction that's undesirable? Or just that to maintain HMP there is a
>> >> > certain amount of duplication? Or even the less-than-perfect
>> >> > readline/completion aspects?
>> >> 
>> >> Over time we've been gradually separating our human targetted code from
>> >> our machine targetted code, whether that's command line argument parsing,
>> >> or monitor parsing. Maintaining two ways todo the same thing is always
>> >> going to be a maint burden, and in QEMU it has been especially burdensome
>> >> as they were parallel impls in many cases, rather than one being exclusively
>> >> built on top of the other.
>> >> 
>> >> Even today we still get contributors sending patches which only impl
>> >> HMP code and not QMP code. Separating HMP fully from QMP so that it
>> >> was mandatory to create QMP first gets contributors going down the
>> >> right path, and should reduce the burden on maint.
>> >
>> > Having a separate HMP isn't a bad idea - but it does need some idea of
>> > how to make it easy for contributors to add stuff that's just for debug
>> > or for the dev.   For HMP the bar is very low; if it's useful to the
>> > dev, why not (unless it's copying something that's already in the QMP interface
>> > in a different way);  but although the x- stuff in theory lets
>> > you add something via QMP, in practice it's quite hard to get it through
>> > review without a lot of QMP design bikeshedding.
>> 
>> I think this description has become less accurate than it used to be :)
>> 
>> A long time ago, we started with "QMP is a stable, structured interface
>> for machines, HMP is a plain text interface for humans, and layered on
>> top of QMP."  Layered on top means HMP commands wrap around QMP
>> commands.  Ensures that QMP is obviously complete.  Without such a
>> layering, we'd have to verify completeness by inspection.  Impractical
>> given the size and complexity of the interfaces involved.
>> 
>> Trouble is there are things in HMP that make no sense in QMP.  For
>> instance, HMP command 'cpu' sets the monitor's default CPU, which
>> certain HMP commands use.  To wrap 'cpu' around a QMP command, we'd have
>> to drag the concept "default CPU" into QMP where it's not wanted.
>
> Surely the isolated HMP monitor code can just keep track of its view
> of a "default" CPU, and then pass an explicit CPU to the QMP commands
> it runs ?

Yes.  It's how HMP works today.

Re: COCONUT-SVSM project ideas for GSoC 2026

[Jörg Rödel]

Hi Stefan,

On Thu, Jan 29, 2026 at 09:18:15AM -0500, Stefan Hajnoczi wrote:
> I think the mentors should provide the extension to the SVSM protocol
> specification. That way the intern can start the coding period by
> diving straight into the implementation and there is no risk that the
> project is held up because the community does not like the design.

Thanks a lot for your feedback. You are right the the project as described is
too big for GSoC.

So we settled on defining the protocol on our own before GSoC starts and
provide it to the student. Updated proposal below:

--->8---
=== Observability Support for COCONUT-SVSM ===

'''Summary:''' Implement Support for COCONUT-SVSM Observability within the TEE

COCONUT-SVSM is a Secure Virtual machine Service Module that runs at a
privileged level within a Confidential Virtual Machine (CVM) to provide trusted
services, such as a virtual TPM, to the guest operating system, independent of
the host hypervisor.

The goal of the project is to implement basic support for observability
of COCONUT-SVSM from the guest OS. When finished the guest OS has a way
to fetch runtime metrics and data from the COCONUT-SVSM running within
the same TEE. Runtime data includes the log buffer, memory usage, and
possible future extensions.

The project consists of several parts:

1. Implement a handler for the pre-defined SVSM observability protocol
   within COCONUT-SVSM following the other protocols COCONUT-SVSM
   already implements.
2. Implement a Linux device driver which uses this protocol to get
   observability data from COCONUT-SVSM and make it accessible to Linux user-mode
   via a device file.
3. Implement a Linux user-space utility to fetch and save the observability
   data using the device driver.

'''Links:'''

* COCONUT-SVSM Repository: https://github.com/coconut-svsm/svsm/
* Development plan: https://coconut-svsm.github.io/svsm/developer/DEVELOPMENT-PLAN/#observability
* SVSM protocol specification: https://docs.amd.com/v/u/en-US/58019

'''Details:'''
Skill level: Intermediate
Language: Rust and C
Mentors: Stefano Garzarella <sgarzare@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Joerg Roedel <joerg.roedel@amd.com>
--->8---

-Joerg

Re: COCONUT-SVSM project ideas for GSoC 2026

[Stefan Hajnoczi]

On Wed, Feb 4, 2026 at 8:24 AM Jörg Rödel <joro@8bytes.org> wrote:
>
> Hi Stefan,
>
> On Thu, Jan 29, 2026 at 09:18:15AM -0500, Stefan Hajnoczi wrote:
> > I think the mentors should provide the extension to the SVSM protocol
> > specification. That way the intern can start the coding period by
> > diving straight into the implementation and there is no risk that the
> > project is held up because the community does not like the design.
>
> Thanks a lot for your feedback. You are right the the project as described is
> too big for GSoC.
>
> So we settled on defining the protocol on our own before GSoC starts and
> provide it to the student. Updated proposal below:

Excellent! I posted your project description here:
https://wiki.qemu.org/Google_Summer_of_Code_2026#Observability_Support_for_COCONUT-SVSM

Please add a link to the protocol by February 19th when accepted
organizations will be announced and interns can begin researching
project ideas.

Thanks,
Stefan

Re: Modern HMP

[Dr. David Alan Gilbert]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dave@treblig.org> writes:
> 
> > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> >> On Thu, Jan 22, 2026 at 12:47:47PM -0300, Fabiano Rosas wrote:
> >> > One question I have is what exactly gets (eventually) removed from QEMU
> >> > and what benefits we expect from it. Is it the entire "manual"
> >> > interaction that's undesirable? Or just that to maintain HMP there is a
> >> > certain amount of duplication? Or even the less-than-perfect
> >> > readline/completion aspects?
> >> 
> >> Over time we've been gradually separating our human targetted code from
> >> our machine targetted code, whether that's command line argument parsing,
> >> or monitor parsing. Maintaining two ways todo the same thing is always
> >> going to be a maint burden, and in QEMU it has been especially burdensome
> >> as they were parallel impls in many cases, rather than one being exclusively
> >> built on top of the other.
> >> 
> >> Even today we still get contributors sending patches which only impl
> >> HMP code and not QMP code. Separating HMP fully from QMP so that it
> >> was mandatory to create QMP first gets contributors going down the
> >> right path, and should reduce the burden on maint.
> >
> > Having a separate HMP isn't a bad idea - but it does need some idea of
> > how to make it easy for contributors to add stuff that's just for debug
> > or for the dev.   For HMP the bar is very low; if it's useful to the
> > dev, why not (unless it's copying something that's already in the QMP interface
> > in a different way);  but although the x- stuff in theory lets
> > you add something via QMP, in practice it's quite hard to get it through
> > review without a lot of QMP design bikeshedding.
> 
> I think this description has become less accurate than it used to be :)
> 
> A long time ago, we started with "QMP is a stable, structured interface
> for machines, HMP is a plain text interface for humans, and layered on
> top of QMP."  Layered on top means HMP commands wrap around QMP
> commands.  Ensures that QMP is obviously complete.  Without such a
> layering, we'd have to verify completeness by inspection.  Impractical
> given the size and complexity of the interfaces involved.
> 
> Trouble is there are things in HMP that make no sense in QMP.  For
> instance, HMP command 'cpu' sets the monitor's default CPU, which
> certain HMP commands use.  To wrap 'cpu' around a QMP command, we'd have
> to drag the concept "default CPU" into QMP where it's not wanted.

That's just state; that's easy!

> So we retreated from "all", and permitted exceptions for commands that
> make no sense in QMP.
> 
> We then found out the hard & expensive way that designing a QMP command
> with its stable, structured interface is often a lot harder than
> cobbling together an HMP command.  It's not just avoidable social
> problems ("bikeshedding"); designing stable interfaces is just hard.
> Sometimes the extra effort is worthwhile.  Sometimes it's not, e.g. when
> all we really want is print something to aid a human with debugging.

Right.

> So we retreated from "all" some more, and permitted exceptions for
> commands meant exclusively for human use, typically debugging and
> development aids.
> 
> This effectifely redefined the meaning of "complete": instead of "QMP
> can do everything HMP can do and more", it's now "... except for certain
> development and debugging aids and maybe other stuff".
> 
> To keep "maybe other stuff" under control, we required (and still
> require) an *argument* for adding functionality just to HMP.
> 
> This turned out to be differently bothersome.  Having to review HMP
> changes for QMP bypasses is bothersome, and bound to miss things at
> least occasionally.  Having to ask for an argument is bothersome.
> Constructing one is bothersome.

Well, it's not too bad as long as the arguments are only asked to be
reasonable rather than bulletproof.

> To reduce the bother, we retreated from another QMP ideal: the
> structured interface.  Permit QMP commands to return just text when the
> command is meant just for humans.  Such commands must be unstable.
> Possible because we had retreated from "all of QMP is stable" meanwhile.
> 
> How does this work?  Instead of adding an HMP-only command, add a QMP
> command that returns QAPI type HumanReadableText, and a trivial HMP
> command that wraps around it.  Slightly more work, but no interface
> design.

Yes, I've seen that - and as long as that continues it's OK;
although it does feel weird in a few ways; it seems more work
to implement than just being able to print, but I do worry
what happens with commands with a lot of output.   It also gets
weirder when you have to parameterise it, because you get the parameter
parsing in one place influencing the separate formatting.

> The QMP command addition is much more visible to the QAPI/QMP
> maintainers than an HMP-only command would be.  This helps avoid missing
> things.
> 
> We still want an argument why a structured interface isn't needed.  But
> we can be much more lenient there: if it turns out to be needed, we can
> just add it, and drop the unstructured interface.  Remember, it's
> unstable.
> 
> Hope this helps.

Yeh, it's just something to be watchful of.

I did see you suggesting for Rust for it; which would work - although
given it wouldn't be performance sensitive, Python would seem reasonable.

Dave

Dave

-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Modern HMP

[Markus Armbruster]

"Dr. David Alan Gilbert" <dave@treblig.org> writes:

[...]

> I did see you suggesting for Rust for it; which would work - although
> given it wouldn't be performance sensitive, Python would seem reasonable.

Marc-André suggested "Python or Rust (student choice)".

Daniel argued for Rust "as it allows the possibility to embed that Rust
impl inside the current QEMU binaries, to fully replace the C code and
retain broadly the same functionality."

If we're not interested in such embedding, then Python feels preferable
to me, because I'd expect it to get us to the finish line faster.

Re: Modern HMP

[Dr. David Alan Gilbert]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dave@treblig.org> writes:
> 
> [...]
> 
> > I did see you suggesting for Rust for it; which would work - although
> > given it wouldn't be performance sensitive, Python would seem reasonable.
> 
> Marc-André suggested "Python or Rust (student choice)".
> 
> Daniel argued for Rust "as it allows the possibility to embed that Rust
> impl inside the current QEMU binaries, to fully replace the C code and
> retain broadly the same functionality."
> 
> If we're not interested in such embedding, then Python feels preferable
> to me, because I'd expect it to get us to the finish line faster.

Ah ok, the either-or embedding thing sounds neat; but does sound like
it would complicate stuff.

Dave

-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/