Re: Where should the vhost-user specification live?

On Thu, Jun 11, 2026 at 04:39:15PM -0400, Stefan Hajnoczi wrote:
> On Wed, Jun 10, 2026 at 09:37:10AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 09, 2026 at 08:51:15PM +0100, Peter Maydell wrote:
> > > On Tue, 9 Jun 2026 at 20:45, Stefan Hajnoczi <[email protected]> wrote:
> > > >
> > > > On Tue, Jun 9, 2026 at 2:51 PM Peter Maydell <[email protected]> wrote:
> > > > >
> > > > > On Tue, 9 Jun 2026 at 19:00, Stefan Hajnoczi <[email protected]> wrote:
> > > > > > 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.
> > 
> > snip
> > 
> > > I tend to view the specs subsection of the docs as being
> > > for things where either QEMU really is the authoritative
> > > source (eg fw_cfg), or where the spec is for something that's
> > > basically moribund and has no better home. If vhost-user is
> > > a cross-project specification that it so active that it
> > > cannot live within QEMU's release process, then I think
> > > it deserves to have its own independent home.
> > 
> > Yes, the main impression I get having read through this whole thread
> > is that vhost-user spec should have its own home outside QEMU.
> > 
> > We can come up with all sorts of rationalizations for how to make
> > things work in the context of QEMU, but they all just come across
> > as excuses to avoid changing the fairly arbitrary historical use
> > of qemu.git. Even if as QEMU maintainers we consider that we're a
> > "neutral" home, I can understand why it might not be perceived that
> > way from the outside.
> > 
> > If people want agility such that we need to make exceptions for
> > our rules during freeze that is one flag that it doesn't belong
> > with the main qemu.git, but there are broader points that are
> > pushing my view in that direction too.
> > 
> > 
> > Not mentioned is that engaging with the QEMU mailing list as a
> > non-regular QEMU contributor is not a very attractive task.
> > While QEMU may be satisfied with email, QEMU are in a tiny
> > minority these days. The rest of the OSS community has
> > decided that git forges are the better way to collaborate.
> > 
> > Our dev list is very high volume, with changes very easily (and
> > often) lost in the noise, even from regular contributors, such
> > that we have to teach people to (repeatedly) "ping" to attract
> > attention.
> 
> A separate repo in a git forge definitely has the advantage of making
> communication easier to follow for anyone interested only in the
> vhost-user protocol.
> 
> > If we want agility though, IMHO it is best to stay away from the
> > bureucracy of the OASIS virtio spec / committee, which is a big
> > turn off IME.
> 
> Yes, OASIS adds overhead.
> 
> The downside is that vhost-user suffers from being outside the VIRTIO
> spec umbrella. It's really a VIRTIO Transport and would benefit from the
> discipline of actually being part of the spec as such. At the moment
> vhost-user is not really bound to VIRTIO through any interface (i.e.
> VIRTIO Transport) or device lifecycle that is guaranteed to align with
> the VIRTIO spec. This has led to both design problems and bugs that
> would be prevented by making it a VIRTIO Transport.
> 
> In addition to the OASIS overhead you mentioned, the other issue is that
> moving vhost-user into the VIRTIO spec would require reconciling the
> the vhost-user protocol with the VIRITO Transport's interface and also
> rewriting parts of the vhost-user spec that are not up to the level
> (e.g. adding conformance clauses, eliminating some informal language,
> etc).

And possibly getting an agreement to OASIS IPR from major past contributors.

> In other words, it's a bunch of work. Although from a purist perspective
> I think it's the right place for vhost-user, I think it would be an
> unpopular solution.
> 
> > If we're considering a move of the spec, we should probably consider
> > the best home for some of the related code parts too:
> > 
> >   subprojects/libvhost-user/
> >   contrib/vhost-user-blk/
> >   contrib/vhost-user-bridge/
> >   contrib/vhost-user-gpu/
> >   contrib/vhost-user-input/
> >   contrib/vhost-user-scsi/
> > 
> > IIUC, the subprojects is fully standalone code with no dependency
> > on QEMU. It remained within QEMU for "convenience" allowing us to
> > consume them from the impls under contrib/. While the contrib code
> > has some depedencies on QEMU, overall they appear pretty light and
> > so likely easily detached
> > 
> >   $ git grep '#include "' vhost-user-* | awk '{print $2}' | sort | uniq
> >   "hw/virtio/virtio-gpu-bswap.h"
> >   "hw/virtio/virtio-gpu-pixman.h"
> >   "libvhost-user-glib.h"
> >   "libvhost-user.h"
> >   "qapi/error.h"
> >   "qemu/atomic.h"
> >   "qemu/bswap.h"
> >   "qemu/ctype.h"
> >   "qemu/drm.h"
> >   "qemu/iov.h"
> >   "qemu/osdep.h"
> >   "qemu/queue.h"
> >   "qemu/sockets.h"
> >   "standard-headers/linux/input.h"
> >   "standard-headers/linux/virtio_blk.h"
> >   "standard-headers/linux/virtio_gpu.h"
> >   "standard-headers/linux/virtio_input.h"
> >   "standard-headers/linux/virtio_net.h"
> >   "standard-headers/linux/virtio_scsi.h"
> >   "virgl.h"
> >   "vugbm.h"
> >   "vugpu.h"
> > 
> > 
> > We have a often repeated desire to eliminate the "contrib" tree
> > as a concept, since it is currently effectively a "dumping ground"
> > for things which are either unmaintained or didn't have a better
> > home yet. This might be a chance to provide a better home for a
> > big part of it.
> > 
> > IMHO this suggests it is worth creating a new top level gitlab project
> > for it all to live in and form a dedicated team around it, rather than
> > trying to pick any existing location.
> 
> Some vhost-user back-ends in the contrib/ directory are used by QEMU's
> test suite. An alternative way of integrating them into the tests could
> be found, but I wanted to mention that dependency.
> 
> Stefan