Hi,
This year at KVM Forum we held the first QEMU Summit. Below are the
minutes from this meeting. We plan to make this an annual event so look
for more information next year as we plan QEMU Summit 2013.
Thanks to everyone who attended and in particular to those that helped
pull together the notes below!
QEMU Summit 2012
================
- Attendees:
- Markus Armbruster
- Paolo Bonzini
- Amit Shah
- Michael Tsirkin
- Michael Roth
- Jason Baron
- Marcelo Tosatti
- Kevin Wolf
- Gerd Hoffmann
- Avi Kivity
- Andreas Färber
- Alex Graf
- Anthony Liguori
- Jan Kiszka
- Peter Maydell
- Stefano Stabellini
- Agenda
- Release management
- Switched from 6-month (roughly 4 1/2 months development + 1 1/2
stabilization) to 3-month (2 months development + 1 stabilization)
release cycle
- Advantages:
- get code out to users (Avi)
- frequent releases (Anthony)
- easier to be conservative about what goes in late (Anthony)
- Disadvantages:
- Stabilisation phase is shorter, worried (Anthony)
- Thundering herd of patches before soft freeze (Peter)
- Stable releases
- Ease most of the problems with a shorter release cycle (Avi)
- Mike Roth does N-1 for the three months of development of N
- Distro guys do extended stable releases (Andreas for 0.15)
- No point in deciding beforehand when a LTS release will
appears: volunteers will come forth
- 1.3 will likely be used by SuSE too
- qemu-stable needs to be used more
- Proactive discovery of stable patches bad, reactive discovery good
- Even better, tag patches for qemu-stable in the commit message
("Cc: qemu-sta...@gnu.org")
- Maintainers should add/remove the tag upon commit, so that
it's easy to mine the commit log for stable candidates
- Having a shorter development window (like Linux)?
- Still too many dependencies between trees
- It's somewhat hard to develop stuff that covers many separate trees
- would make it harder
- Other suggestions
- Get stuff in incrementally
- Submaintainers need to exercise discretion and refuse to pull stuff
- Make sure complex features can stay in the tree disabled, to
have a contingency plan
- Document buildbot
- Maintainership
- Having more maintainers was a success!
- Patches are not disappearing, so even unmaintained areas are covered
decently
- Still, we should add more subtrees whenever it makes sense
- Let maintainers surface naturally
- Pull requests breaking the builds
- Buildbot only submit the first broken build, then go silent
- virtfs-proxy-helper broken on Fedora -> silence & breakage
- In the future, all subtrees should have a buildbot instance
- Sending patches to MAINTAINERS is welcome
- Don't be afraid to remove inactive maintainers or degrade stuff to
Orphaned (was a success for the network devices subsystem)
- Improving modularity should make new areas appear
- Testing
- gtest has limited applicability in the case of QEMU, but provides
decent coverage and needs to be extended
- examples: AioContext, MemoryRegion
- qemu-iotests coverage, while limited, is better than everything else
- qtest needs more complete interfaces to set up devices (PCI, etc.)
- going to add tests for virtio devices, after which a basic test
will become mandatory for new devices
- Anthony to do virtio-blk, Paolo to do virtio-scsi
- It's not an x86-specific thingy! :)
- "make check" should test more stuff
- autotest became finally usable by developers, could be integrated
- There will be (were by the time this is sent) lots of testing talks
at KVM Forum
- If you want X tested, add it to default configure flags!
- Remember that compilers are smart
- Example: --enable-debug-tcg
- Security
- Currently handled mostly by Red Hat's Security Response Team
- RH gets CVEs, etc.
- Informs other vendors
- A coordinated release is prepared
- Improvements
- Add a separate private mailing list
- Write a wiki page about how to report vulnerabilities
- GPLv3
- Let's make clear that QEMU will never be GPLv3 (VFIO for system
emulation, ELF loader for user emulation)
- It may also appease some company lawyers...
- Nevertheless, we want code to be as easily reusable as possible
- Contributions must be GPLv2+ except for very, very good reasons
- ABI, API & plugins
- Plugins will have to be GPL-compatible
- Example: GCC requires plugins to export a "plugin_is_GPL_compatible"
symbol
- Example plugins: Gluster, SPICE, TPM, SDL, VDE
- Limit dependencies for distros
- Simplest implementation: rely on module.c, dlopen all files in a
directory at startup
- Cross-platform implementation is hard
- Integration in the build system might be interesting...
- Our users are guests and management tools, not plugins
- Management APIs are QMP and the command-line
- Guest API/ABI is the virtual hardware, should we document it better?
- No need for in most cases, guests should just write their code to
the spec, not to "features of QEMUv1.something"
- Still, let's link specs in the wiki, or let's write down explicitly
what drivers the code was reverse-engineered from
- No API/ABI guarantees for plugins
- Administrivia
- No success in contacting owner of qemu.org so far
- qemu-project.org was hence bought
- Affiliation to SFC (http://sfconservancy.org),
SPI (http://www.spi-inc.org/) or another foundation
- Simple management of (little) money we have
- Legal advice
- Wrapup
- 3 hours, ~20 people
- Was this useful? Yes
- Not too many topics
- For the future:
- set up mailing list to simplify & formalize the invitation process
- colocation with KVM Forum should make travel funding simple (via
Linux Foundation)
- "QEMU Forum" -- aka what's in a name?
- KVM has branding, companies send you to KVM events not QEMU events :(
- Peter was very happy to have come to KVM Forum 2011
- A session/track for TCG/embedded would be very welcome -- contributors
are welcome to submit proposals to future KVM Forums
