QEMU Summit Minutes 2025

[Peter Maydell <peter.maydell@linaro.org>]

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