On Thu, Jun 4, 2026 at 12:39 PM Stefan Hajnoczi <[email protected]> wrote: > > On Tue, Jun 02, 2026 at 12:38:27PM +0200, Dorinda Bassey wrote: > > Hi All, > > > > Following up on this discussion: Albert, Stefano and I are organizing > > a BoF session on vhost-user for Linux Plumbers Conference, so this > > thread is very timely. > > > > > I get a sense that this is about politics in the end. Do people feel > > > they are not represented and would like to have more influence in the > > > vhost-user spec? > > > > I think the core issue is that vhost-user has grown beyond just QEMU. > > The spec is now implemented by rust-vmm, cloud-hypervisor, crosvm, > > libkrun, and others. All of these projects depend on the spec as their > > source of truth for interoperability. > > vhost-user was always an effort spanning multiple projects - that is > fundamentally the purpose of the vhost-user protocol - so it bothers me > when it is framed this way. CrosVM implemented a vhost-user front-end > years ago. Features have been added to the spec that are not used by > QEMU because the spec is for all front-ends and back-ends and their > different use cases, not just QEMU. > > I'm fine with moving the spec to a separate project if it makes > day-to-day work easier, but it's not accurate to portray vhost-user and > the work that has been done by people from many projects in this way. > > > There are also concrete technical friction points. Let me share some > > examples from rust-vmm: > > > > rust-vmm SHMEM PR https://github.com/rust-vmm/vhost/pull/251 > > We had to wait for QEMU spec acceptance before merging the > > implementation. The spec update was delayed with the comment > > "should get picked for the next round" after QEMU freeze. > > I am happy to merge a vhost-user spec PR into qemu.git during the freeze > if other projects need the spec change. > > > rust-vmm PR https://github.com/rust-vmm/vhost/pull/339 : was > > kept as draft "waiting for QEMU spec changes to be finalized." > > It was eventually merged when they decided the spec was > > "stable enough" even though QEMU hadn't finalized it yet, > > which felt awkward. > > In this particular case the QEMU patch series could have been split into > just the spec change and the QEMU implementation with a note in the > cover letter requesting to merge the spec change right away. I don't > think anything was fundamentally blocking the spec change, although > maintainers might be skeptical about rushing something that is still > work in progress. There was a lack of communication here. > > > When multiple independent implementations wait on one > > project's release cycles, it raises the question of whether the > > governance model matches the ecosystem reality. > > If the experience with QEMU's release cycle is the main point of > friction, then that is easy to solve by merging spec changes even during > freeze.
Hi Michael, It has been a few days and I want to make sure we don't forget this discussion since rust-vmm was inconvenienced by waiting on QEMU's development cycle. I'm not sure if anyone brought up this topic on qemu-devel and with Michael before. As I mentioned in my reply, there are ways to avoid blocking vhost-user spec changes when qemu.git is frozen: The simplest approach is to keep merging vhost-user.rst changes during freeze since it does not jeopardize the release or introduce instability. Another approach is for Michael to merge patches and publish his vhost subsystem branch. This is a common approach that Linux and QEMU sub-maintainers use to share merged work before it reaches the final repo. As long as there is a guarantee that vhost-user.rst changes merged on Michael's vhost branch are stable, front-end and back-end implementers can rely on spec changes in Michael's tree without waiting for qemu.git/master. Moving vhost-user.rst to its own repo also solves this. Any preferences? Stefan > > > > > > Why is the current system not neutral and how will the new system solve > > > that? > > > > For example the virtio-spec has OASIS governance where changes > > are proposed and merged independently of any implementation's release > > cycle. Whether that's the right model for vhost-user is worth discussing. > > > > > You bring up project neutrality and a model where Michael is no longer > > > the sole maintainer. It will be necessary to propose a concrete roadmap > > > and also to explain the concerns about neutrality more so it's clear > > > they won't be an issue anymore in the future system. > > > > You're right that we need a concrete roadmap before making changes. > > More reason to discuss in the BoF - to work this out with the people > > actually doing the work: you, Michael, Albert, and others who've been > > deeply involved. Maybe in the end the solution might be to "improve > > QEMU's process" (like Michael's submodule suggestion) rather than > > "move the spec." or something else? that's what we need to figure out > > together. > > > > Would folks here be interested in joining the discussion at Plumbers? > > Plumbers in October? How about scheduling a video call in the next few > days instead of waiting. That will allow anyone to attend. > > Stefan
