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