On Tue, Jun 9, 2026 at 8:59 PM Stefan Hajnoczi <[email protected]> wrote: > > 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. I think this is the sanest and simplest solution. vhost-user.rst changes do not need to go to master, a guarantee that they will get submitted as a PR against master is enough. > > 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
