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
January 30th.

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

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

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

=== TITLE ===

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

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

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

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

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

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

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Peter Xu]

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

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

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

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

Thanks,

=== Fast Snapshot Load ===

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

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

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

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

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

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

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

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

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

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

-- 
Peter Xu

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

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

Feel free to edit the project idea on the wiki.

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Peter Xu]

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

Looks good, thanks Stefan.

-- 
Peter Xu

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nice.

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

Yes!

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

Stefan

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

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

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

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

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

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

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

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

'''Project Goals:'''

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

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

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

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

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

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


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

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

Re: Call for GSoC internship project ideas

[Thomas Huth]

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

  Thomas

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

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

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

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

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

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


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

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

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

This would have a number of other benefits

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

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

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

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

 * Tiny & fast downloads of pre-built images.


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

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


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

Re: Call for GSoC internship project ideas

[Marc-André Lureau]

Hi

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


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

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


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

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

Imho, building all images from scratch cannot be sustainable.

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

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

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

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

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

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

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

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

Re: Call for GSoC internship project ideas

[Peter Maydell]

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

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

thanks
-- PMM

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

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

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

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

Re: Call for GSoC internship project ideas

[Marc-André Lureau]

Hi

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

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

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

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

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

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

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

Re: Call for GSoC internship project ideas

[Alex Bennée]

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

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

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

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC internship project ideas

[Pierrick Bouvier]

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

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

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

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

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

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

Just my 2 cents,
Pierrick

Re: Call for GSoC internship project ideas

[Marc-André Lureau]

Hi

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

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

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

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

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


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

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

--
Marc-André Lureau

Re: Call for GSoC internship project ideas

[Pierrick Bouvier]

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

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

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

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

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

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

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

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

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

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

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

Regards,
Pierrick

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

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

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Stefano Garzarella]

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

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

Sorry for the delay,
Stefano

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

Great, I'm looking forward to adding them.

Stefan

Re: Call for GSoC internship project ideas

[Thomas Huth]

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

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

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

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

  Thomas

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

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

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

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

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

Re: Call for GSoC internship project ideas

[Thomas Huth]

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

Ah, sorry for getting that wrong!

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

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

  Thomas


  Thomas

Re: Call for GSoC internship project ideas

[Daniel P. Berrangé]

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

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

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

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

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

Re: Call for GSoC internship project ideas

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

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

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

>
>  Thomas
>
>
>  Thomas

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

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

Stefan

Re: Call for GSoC internship project ideas

[Alex Bennée]

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

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

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

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

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

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC internship project ideas

[John Levon]

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

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

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

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

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

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

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

regards
john

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

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

=== External HMP Implementation via QMP ===

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

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

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

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

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

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

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

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

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

* Seamless replacement of built-in HMP

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

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

Stefan

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: 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: 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: 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: 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: 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   |_______/

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

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

Hello,

We came up with the following idea.

Thanks.

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

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

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

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

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

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

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

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

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

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

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

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

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

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

Feel free to edit the project idea on the wiki.

Stefan

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