Re: Where should the vhost-user specification live?

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4047 bytes --]

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.

> 
> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]