Re: Where should the vhost-user specification live?

On Tue, Jun 9, 2026 at 8:59=E2=80=AFPM Stefan Hajnoczi <[email protected]>=
 wrote:
>
> On Thu, Jun 4, 2026 at 12:39=E2=80=AFPM Stefan Hajnoczi <stefanha@redhat.=
com> 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 fee=
l
> > > > they are not represented and would like to have more influence in t=
he
> > > > 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 thei=
r
> > > 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 freez=
e
> > 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 int=
o
> > 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 durin=
g
> > 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 s=
olve
> > > > 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 discuss=
ing.
> > >
> > > > You bring up project neutrality and a model where Michael is no lon=
ger
> > > > the sole maintainer. It will be necessary to propose a concrete roa=
dmap
> > > > and also to explain the concerns about neutrality more so it's clea=
r
> > > > 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