QEMU Summit Minutes 2025

QEMU Summit Minutes 2025

[Peter Maydell]

As usual, we held a QEMU Summit meeting at KVM Forum.  This is an
invite-only meeting for the most active maintainers and submaintainers
in the project, and we discuss various project-wide issues, usually
process stuff. We then post the minutes of the meeting to the list as
a jumping off point for wider discussion and for those who weren't
able to attend.

Attendees
=========

Markus Armbruster
Alex Bennée
Daniel P. Berrangé
Paolo Bonzini
Mark Cave-Ayland
Alex Graf
Stefan Hajnoczi
Richard Henderson
Thomas Huth
Cédric Le Goater
Philippe Mathieu-Daudé
Peter Maydell
Michael S. Tsirkin
Kevin Wolf
David Woodhouse

Agenda
======

Finances
--------

- The KVM Forum conference made a small profit; as with last year, we
  plan to use this to help with the financing of the conference in
  future years.

CI
--

- We have an Azure -> AWS CI hosting migration coming up as we have no
  more Azure credits and we have AWS credits now.
- CI is still unreliable. We need to be more proactive at reporting
  failures. qemu.git maintainers should submit issues when tests are
  flaky so that test owners and private runner owners are aware of
  test problems.

AI policy
---------

- Following the publication of our initial AI policy, there was discussion
  about whether there had been any initial feedback or if there were
  tweaks we wanted to make to it.

- Generally there didn't seem to have been much feedback so far (from
  actual developers as opposed to the peanut gallery). The general
  principle behind the policy is to protect the project from legal risks
  related to copyright and license status of the output. There was
  some discussion of whether there were simple useful cases where we
  would be willing to take AI tool output that was an essentially
  mechanical transformation with "limited creative content".

- There was no consensus in the meeting on whether we should
  consider this sort of change to the policy now, or whether we
  should give the initial policy some time, and collect feedback
  based on that longer term experience before making changes.

- There is a patch on the mailing list proposing a change
  to the policy to allow this kind of "limited creative content"
  contribution:
  https://lore.kernel.org/qemu-devel/20250925075630.352720-1-pbonzini@redhat.com/

- We plan to solicit feedback in spring next year on how the policy has
  worked out in practice.

Release tarballs
----------------

- Our release tarballs are quite large, and 85% of them is just the
  source of EDK2 which we include as the corresponding source for the
  EDK2 ROM blobs. This seems a bit silly, since most consumers of the
  tarball are either:
   - downstream distros who will want to build their own ROM blobs
     from the real upstream sources
   - end users who don't want to build the ROM blobs at all

- We could perhaps usefully split the tarballs so that the ROM sources
  and the ROM blobs are in their own tarballs and only people who need
  them download them.

- Relatedly, it would be nice for the ROM blobs to be trivially
  regenerable by anybody, rather than the current ad-hoc "some
  trusted person builds a binary locally and we commit it to git"
  setup. This should be much easier in these days of containers than
  it was when we first started committing compiled blobs to git.

- However, nothing is fundamentally broken with our current setup, so
  unless anybody who really wants to do this work is going to step
  up we probably won't do anything ;-)

Shifting styles and incomplete API conversions
----------------------------------------------

- The project has lots of ways of achieving similar things with qdev, QOM,
  etc. This makes it hard for contributors and reviewers to know how
  something should be written, or which style to recommend in review.
  Being asked to change APIs/style is disheartening.
  This is unlikely to be something we can address easily, but some
  things to aim for that came up in the conversation:
  - we should be clear which APIs are legacy and must not be used in
    new code
  - we should update the old "unfinished transition" wiki page

- In particular, there is no current consensus on QOM casts
  - Using the cast macros looks the neatest stylistically
  - But it has a runtime overhead, which is irksome in cases where
    actually at compile time we can be certain the pointer is of
    a valid type (e.g. cast to parent type)
  - Different reviewers put different weight on these factors,
    causing conflicts about what to prefer.


thanks
-- PMM

Re: QEMU Summit Minutes 2025

[BALATON Zoltan]

On Fri, 17 Oct 2025, Peter Maydell wrote:
> Release tarballs
> ----------------
>
> - Our release tarballs are quite large, and 85% of them is just the
>  source of EDK2 which we include as the corresponding source for the
>  EDK2 ROM blobs. This seems a bit silly, since most consumers of the
>  tarball are either:
>   - downstream distros who will want to build their own ROM blobs
>     from the real upstream sources
>   - end users who don't want to build the ROM blobs at all
>
> - We could perhaps usefully split the tarballs so that the ROM sources
>  and the ROM blobs are in their own tarballs and only people who need
>  them download them.

Wouldn't this be solved by splitting off the EDK2 version QEMU needs into 
a separate project (something like qemu-edk2) and make that a separate 
dependency?

> - Relatedly, it would be nice for the ROM blobs to be trivially
>  regenerable by anybody, rather than the current ad-hoc "some
>  trusted person builds a binary locally and we commit it to git"
>  setup. This should be much easier in these days of containers than
>  it was when we first started committing compiled blobs to git.

Having blobs is a big conveniece that would be preferable to keep as most 
of the time people don't need to rebuild blobs if they just want to run a 
machine and even if changing a machine they don't need to touch the 
firmware so it's only a few people who may want to install cross compilers 
or a container to rebuild blobs and it would be nice to save others that 
hassle.

> - However, nothing is fundamentally broken with our current setup, so
>  unless anybody who really wants to do this work is going to step
>  up we probably won't do anything ;-)
>
> Shifting styles and incomplete API conversions
> ----------------------------------------------
>
> - The project has lots of ways of achieving similar things with qdev, QOM,
>  etc. This makes it hard for contributors and reviewers to know how
>  something should be written, or which style to recommend in review.
>  Being asked to change APIs/style is disheartening.
>  This is unlikely to be something we can address easily, but some
>  things to aim for that came up in the conversation:
>  - we should be clear which APIs are legacy and must not be used in
>    new code
>  - we should update the old "unfinished transition" wiki page

It should be clearly documented which is not always the case and in those 
cases existing examples are taken as documentation. So where there is a 
preferred API that should be in the documentation or if it's already there 
should somehow be more organised so it's easier to find and refer to in 
reviews.

> - In particular, there is no current consensus on QOM casts
>  - Using the cast macros looks the neatest stylistically
>  - But it has a runtime overhead, which is irksome in cases where
>    actually at compile time we can be certain the pointer is of
>    a valid type (e.g. cast to parent type)
>  - Different reviewers put different weight on these factors,
>    causing conflicts about what to prefer.

This may have been sparked by some of the debates we had with Mark. In one 
review 
[https://patchew.org/QEMU/cover.1758219840.git.balaton@eik.bme.hu/b5b4558125e2408ded29f7cdc306011358829044.1758219840.git.balaton@eik.bme.hu/] 
he proposed memory region callbacks to take device state as opaque data 
then QOM cast these to get the memory region, parent object or field the 
callbacks need. I argued that there's no such convention documented 
anywhere and what the opaque pointer should be is defined by the callbacks 
[https://en.wikipedia.org/wiki/Closure_(computer_programming)#Callbacks_(C)] 
so it makes sense to pass a the data it needs to the callback and not the 
whole device state. Also the opaque data is registered once typically in 
an init or realize function where it's already known it's the right type 
so within the callback (which can potentially be called often) there is no 
need to type check and cast it every time again. So opaque asignments in 
the callback can assume the right type without casting and I don't think 
it would bring any advantage to restrict the type to device state for 
callbacks that would only make them unnecessarily more complex. This isn't 
documented so can lead to different people following different views. Also 
sometimes new conventions are only agreed on the list but not documented 
so who missed the discussion won't know about it.

I would like to raise another point here: PPC maintainership. Is there an 
active maintainer for PPC currently? The one who is listed in MAINTAINERS 
does not seem to be active and nobody seems to review and merge patches I 
submit for PPC which already resulted in missing one release and the next 
one may be the second release my series miss because of this. Is the 
project aware of this and somebody is taking care of it?

Regards,
BALATON Zoltan

Re: QEMU Summit Minutes 2025

[Peter Maydell]

On Fri, 17 Oct 2025 at 13:53, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Fri, 17 Oct 2025, Peter Maydell wrote:
> > Release tarballs
> > ----------------
> >
> > - Our release tarballs are quite large, and 85% of them is just the
> >  source of EDK2 which we include as the corresponding source for the
> >  EDK2 ROM blobs. This seems a bit silly, since most consumers of the
> >  tarball are either:
> >   - downstream distros who will want to build their own ROM blobs
> >     from the real upstream sources
> >   - end users who don't want to build the ROM blobs at all
> >
> > - We could perhaps usefully split the tarballs so that the ROM sources
> >  and the ROM blobs are in their own tarballs and only people who need
> >  them download them.
>
> Wouldn't this be solved by splitting off the EDK2 version QEMU needs into
> a separate project (something like qemu-edk2) and make that a separate
> dependency?

EDK2 is only special here because it happens to be huge. If
we're going to not have "one single huge tarball" then the question
is "what should the split be?".

> > - Relatedly, it would be nice for the ROM blobs to be trivially
> >  regenerable by anybody, rather than the current ad-hoc "some
> >  trusted person builds a binary locally and we commit it to git"
> >  setup. This should be much easier in these days of containers than
> >  it was when we first started committing compiled blobs to git.
>
> Having blobs is a big conveniece that would be preferable to keep as most
> of the time people don't need to rebuild blobs if they just want to run a
> machine and even if changing a machine they don't need to touch the
> firmware so it's only a few people who may want to install cross compilers
> or a container to rebuild blobs and it would be nice to save others that
> hassle.

Yeah. I think we would still commit the compiled blobs to git;
this bullet point is more about "make it more reproducible
so anybody, or perhaps our CI system in an automated job,
can create the blobs to be committed".

One idea I think that was suggested in the meeting was that
we could make our build system say "if the blobs aren't present
locally, download the blob tarball the way we do for various other
dependencies we might download at build time". That would make
things "just work" for most people while maintaining the separation
of blobs and blob-sources from QEMU's actual sources.

> > - However, nothing is fundamentally broken with our current setup, so
> >  unless anybody who really wants to do this work is going to step
> >  up we probably won't do anything ;-)

But also notice this part -- if anybody wants to tackle the
problem they get to define it and also do requirements
collection...

-- PMM