Re: Where should the vhost-user specification live?

On Thu, Jun 11, 2026 at 04:45:10PM -0400, Michael S. Tsirkin wrote:
>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.
>>

Yep, agree on this.

About the current workflow, Working on both QEMU and rust-vmm, I've seen 
people a bit scared by the QEMU review process when all they want is to 
propose a protocol change. As Daniel pointed out, our mailing list is 
high volume and unfamiliar to many. That's a real barrier both for 
contributors and perhaps also for those who would like to follow the 
development.

What about creating a new organization (e.g. "virtio") on gitlab or 
github, and hosting the vhost-user spec there in its own repo, using 
MRs/PRs for changes?

Under the same organization we could keep a read-only mirror of the 
OASIS virtio-spec repo. That wouldn't change virtio governance in any 
way, OASIS stays the authoritative source, but it gives a single place 
to find everything virtio-related.
As a side note, it could also serve as a starting point if the virtio 
community ever wanted to move the spec outside OASIS, but that's 
a completely separate discussion and not something I'm pushing for.

For the vhost-user spec itself, I think we should invite co-maintainers 
from other projects, and keep requiring a broadly complete 
implementation before merging non-trivial spec changes, but that's what 
we already tried to do for both vhost-user and virtio spce changes.

That said, honestly, this might lead to fragmentation (although the goal 
is to create a single hub for virtio), so perhaps the idea of having a 
repository in QEMU gitlab or rust-vmm github might be better.

I'm happy to help with the setup if we reach consensus.

Thanks,
Stefano