Where should the vhost-user specification live?

Where should the vhost-user specification live?

[Alex Bennée]

Hi,

Apologies for the wide cross-posting but I wanted to find as many
interested parties as possible.

The vhost-user specification currently lives in the main qemu
repository (docs/interop/vhost-user.rst) mainly due to historical
reasons. QEMU was one of the first VMMs to implement vhost-user and the
spec needed to live somewhere.

However there are now vhost-user implementations for QEMU, rust-vmm,
cloud hypervisor and I think CrosVM. We get queries about changing or
updating the spec on qemu-devel from time to time and I feel that given
it is an interoperability specification we should think about hosting
it and its discussions elsewhere.

I think broadly there are 4 options:

  *  Move into the OASIS VirtIO group as an appendix/addendum to the main
     VirtIO spec.

     This probably brings the widest visibility to changes to those that
     might be affected. However it does come with a certain amount of
     bureaucracy with the OASIS process where only members can vote on
     changes. While intimately tied to VirtIO it's concerns are more
     focused on practical implementation details of the IPC between VMMs
     and device backends.

  * Move to a separate project under the qemu-project space.

    QEMU hosts a number of sub-projects and mirrors so it would be easy
    enough to split the spec into its own repo. Changes to the
    specification could then be divorced from QEMU's release cycle and
    at the maintainers option issues and merging strategies could be
    configured for just the specification.

  * Create a new project just for vhost-user

    The interested parties could decide where to host (github, gitlab,
    forgejo, whatever..) and decide to move away from mailing lists
    altogether or create a mailing list but manage changes via the forge
    interface.

  * Status quo

    Just keep the spec where it is and muddle through as before. Maybe
    we could improve the contribution documentation for how and when
    changes are discussed.

Any thoughts?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Where should the vhost-user specification live?

[Michael S. Tsirkin]

On Wed, May 27, 2026 at 10:13:47AM +0100, Alex Bennée wrote:
> 
> Hi,
> 
> Apologies for the wide cross-posting but I wanted to find as many
> interested parties as possible.
> 
> The vhost-user specification currently lives in the main qemu
> repository (docs/interop/vhost-user.rst) mainly due to historical
> reasons. QEMU was one of the first VMMs to implement vhost-user and the
> spec needed to live somewhere.
> 
> However there are now vhost-user implementations for QEMU, rust-vmm,
> cloud hypervisor and I think CrosVM. We get queries about changing or
> updating the spec on qemu-devel from time to time and I feel that given
> it is an interoperability specification we should think about hosting
> it and its discussions elsewhere.
> 
> I think broadly there are 4 options:
> 
>   *  Move into the OASIS VirtIO group as an appendix/addendum to the main
>      VirtIO spec.
> 
>      This probably brings the widest visibility to changes to those that
>      might be affected. However it does come with a certain amount of
>      bureaucracy with the OASIS process where only members can vote on
>      changes. While intimately tied to VirtIO it's concerns are more
>      focused on practical implementation details of the IPC between VMMs
>      and device backends.
> 
>   * Move to a separate project under the qemu-project space.
> 
>     QEMU hosts a number of sub-projects and mirrors so it would be easy
>     enough to split the spec into its own repo. Changes to the
>     specification could then be divorced from QEMU's release cycle and
>     at the maintainers option issues and merging strategies could be
>     configured for just the specification.
> 
>   * Create a new project just for vhost-user
> 
>     The interested parties could decide where to host (github, gitlab,
>     forgejo, whatever..) and decide to move away from mailing lists
>     altogether or create a mailing list but manage changes via the forge
>     interface.
> 
>   * Status quo
> 
>     Just keep the spec where it is and muddle through as before. Maybe
>     we could improve the contribution documentation for how and when
>     changes are discussed.
> 
> Any thoughts?
> 
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

I think what is missing here is what are the pros for any of the
proposed changed?  What are the issues we are trying to solve?
What 'queries about changing or updating the spec' were problematic?

Thanks,

-- 
MST

Re: Where should the vhost-user specification live?

[Alex Bennée]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Wed, May 27, 2026 at 10:13:47AM +0100, Alex Bennée wrote:
>> 
>> Hi,
>> 
>> Apologies for the wide cross-posting but I wanted to find as many
>> interested parties as possible.
>> 
>> The vhost-user specification currently lives in the main qemu
>> repository (docs/interop/vhost-user.rst) mainly due to historical
>> reasons. QEMU was one of the first VMMs to implement vhost-user and the
>> spec needed to live somewhere.
>> 
>> However there are now vhost-user implementations for QEMU, rust-vmm,
>> cloud hypervisor and I think CrosVM. We get queries about changing or
>> updating the spec on qemu-devel from time to time and I feel that given
>> it is an interoperability specification we should think about hosting
>> it and its discussions elsewhere.
>> 
>> I think broadly there are 4 options:
>> 
>>   *  Move into the OASIS VirtIO group as an appendix/addendum to the main
>>      VirtIO spec.
>> 
>>      This probably brings the widest visibility to changes to those that
>>      might be affected. However it does come with a certain amount of
>>      bureaucracy with the OASIS process where only members can vote on
>>      changes. While intimately tied to VirtIO it's concerns are more
>>      focused on practical implementation details of the IPC between VMMs
>>      and device backends.
>> 
>>   * Move to a separate project under the qemu-project space.
>> 
>>     QEMU hosts a number of sub-projects and mirrors so it would be easy
>>     enough to split the spec into its own repo. Changes to the
>>     specification could then be divorced from QEMU's release cycle and
>>     at the maintainers option issues and merging strategies could be
>>     configured for just the specification.
>> 
>>   * Create a new project just for vhost-user
>> 
>>     The interested parties could decide where to host (github, gitlab,
>>     forgejo, whatever..) and decide to move away from mailing lists
>>     altogether or create a mailing list but manage changes via the forge
>>     interface.
>> 
>>   * Status quo
>> 
>>     Just keep the spec where it is and muddle through as before. Maybe
>>     we could improve the contribution documentation for how and when
>>     changes are discussed.
>> 
>> Any thoughts?
>> 
>> -- 
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro
>
> I think what is missing here is what are the pros for any of the
> proposed changed?  What are the issues we are trying to solve?
> What 'queries about changing or updating the spec' were problematic?

I was referring to:

  https://lore.kernel.org/qemu-devel/20260522-vhost-user-dev-v1-1-b31646cf19b8@gmail.com

when Demi proposed discussing at the QEMU/KVM community call meeting and
it occurred to me changes to vhost-user affect more than QEMU these days.

>
> Thanks,

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Where should the vhost-user specification live?

[Albert Esteve]

Hi Alex,

On Wed, May 27, 2026 at 11:13 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Hi,
>
> Apologies for the wide cross-posting but I wanted to find as many
> interested parties as possible.
>
> The vhost-user specification currently lives in the main qemu
> repository (docs/interop/vhost-user.rst) mainly due to historical
> reasons. QEMU was one of the first VMMs to implement vhost-user and the
> spec needed to live somewhere.
>
> However there are now vhost-user implementations for QEMU, rust-vmm,
> cloud hypervisor and I think CrosVM. We get queries about changing or
> updating the spec on qemu-devel from time to time and I feel that given
> it is an interoperability specification we should think about hosting
> it and its discussions elsewhere.

We recently discussed this with Dorinda and Stefano. I do see value in
moving it elsewhere. Mainly to remove the friction of external
communities navigating QEMU-specific tooling and workflows just to
propose protocol updates. But also because, in my opinion, separating
the specification would improve development agility by decoupling
specification development from QEMU's review and release cycles.

At least it is worth the discussion. Thanks for raising.

>
> I think broadly there are 4 options:
>
>   *  Move into the OASIS VirtIO group as an appendix/addendum to the main
>      VirtIO spec.
>
>      This probably brings the widest visibility to changes to those that
>      might be affected. However it does come with a certain amount of
>      bureaucracy with the OASIS process where only members can vote on
>      changes. While intimately tied to VirtIO it's concerns are more
>      focused on practical implementation details of the IPC between VMMs
>      and device backends.

While it does make sense for VirtIO, I'm wary of the added bureaucracy
that OASIS would introduce for vhost-user. The scope for vhost-user is
also much smaller, focusing more on the transport protocol as you
pointed out, so I do not see the need to subject ourselves to that
process.

>
>   * Move to a separate project under the qemu-project space.
>
>     QEMU hosts a number of sub-projects and mirrors so it would be easy
>     enough to split the spec into its own repo. Changes to the
>     specification could then be divorced from QEMU's release cycle and
>     at the maintainers option issues and merging strategies could be
>     configured for just the specification.
>
>   * Create a new project just for vhost-user
>
>     The interested parties could decide where to host (github, gitlab,
>     forgejo, whatever..) and decide to move away from mailing lists
>     altogether or create a mailing list but manage changes via the forge
>     interface.
>
>   * Status quo
>
>     Just keep the spec where it is and muddle through as before. Maybe
>     we could improve the contribution documentation for how and when
>     changes are discussed.
>
> Any thoughts?

Another option could be rust-vmm. It is a project shared by multiple
stakeholders. And while it is Rust-focused, its community heavily
overlaps with the exact ecosystems driving modern vhost-user
development.

BR,
Albert

>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>

Re: Where should the vhost-user specification live?

[Michael S. Tsirkin]

On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
>  But also because, in my opinion, separating
> the specification would improve development agility by decoupling
> specification development from QEMU's review and release cycles.

Generally for QEMU this will be less agility, unless I misunderstand
what is proposed)

Because presumably there will need to be spec releases then?

So
	new feature -> spec tree -> spec release -> qemu implementation -> qemu release

is surely longer that what we have now.

Whether there will be more agility for non qemu users will depend on
how often spec releases are cut.



-- 
MST

Re: Where should the vhost-user specification live?

[Albert Esteve]

On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> >  But also because, in my opinion, separating
> > the specification would improve development agility by decoupling
> > specification development from QEMU's review and release cycles.
>
> Generally for QEMU this will be less agility, unless I misunderstand
> what is proposed)
>
> Because presumably there will need to be spec releases then?
>
> So
>         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
>
> is surely longer that what we have now.

I see your point.

However, we do not really need to introduce a heavy release management
layer. We could just operate it as a living document, where the main
branch is the authoritative source of truth.

For the workflow, development doesn't have to be strictly sequential
either. A contributor can propose the spec update while working on the
implementation, much like we do for VirtIO updates. Actually, this way
one update/change supports the other.

I guess my point is that a dedicated repository could lower the
barrier for new changes AND keep QEMU's own development speed mostly
unaffected.

BR,
Albert

>
> Whether there will be more agility for non qemu users will depend on
> how often spec releases are cut.
>
>
>
> --
> MST
>

Re: Where should the vhost-user specification live?

[Michael S. Tsirkin]

On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > >  But also because, in my opinion, separating
> > > the specification would improve development agility by decoupling
> > > specification development from QEMU's review and release cycles.
> >
> > Generally for QEMU this will be less agility, unless I misunderstand
> > what is proposed)
> >
> > Because presumably there will need to be spec releases then?
> >
> > So
> >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> >
> > is surely longer that what we have now.
> 
> I see your point.
> 
> However, we do not really need to introduce a heavy release management
> layer. We could just operate it as a living document, where the main
> branch is the authoritative source of truth.
> 
> For the workflow, development doesn't have to be strictly sequential
> either. A contributor can propose the spec update while working on the
> implementation, much like we do for VirtIO updates. Actually, this way
> one update/change supports the other.
> 
> I guess my point is that a dedicated repository could lower the
> barrier for new changes AND keep QEMU's own development speed mostly
> unaffected.
> 
> BR,
> Albert

Something something submodule? Possibly. If you want to make progress
on this, pls think of the process, try it out.

> >
> > Whether there will be more agility for non qemu users will depend on
> > how often spec releases are cut.
> >
> >
> >
> > --
> > MST
> >

Re: Where should the vhost-user specification live?

[Michael S. Tsirkin]

On Mon, Jun 01, 2026 at 09:51:40AM -0400, Stefan Hajnoczi wrote:
> On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > > > >  But also because, in my opinion, separating
> > > > > the specification would improve development agility by decoupling
> > > > > specification development from QEMU's review and release cycles.
> > > >
> > > > Generally for QEMU this will be less agility, unless I misunderstand
> > > > what is proposed)
> > > >
> > > > Because presumably there will need to be spec releases then?
> > > >
> > > > So
> > > >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> > > >
> > > > is surely longer that what we have now.
> > >
> > > I see your point.
> > >
> > > However, we do not really need to introduce a heavy release management
> > > layer. We could just operate it as a living document, where the main
> > > branch is the authoritative source of truth.
> > >
> > > For the workflow, development doesn't have to be strictly sequential
> > > either. A contributor can propose the spec update while working on the
> > > implementation, much like we do for VirtIO updates. Actually, this way
> > > one update/change supports the other.
> > >
> > > I guess my point is that a dedicated repository could lower the
> > > barrier for new changes AND keep QEMU's own development speed mostly
> > > unaffected.
> > >
> > > BR,
> > > Albert
> >
> > Something something submodule? Possibly. If you want to make progress
> > on this, pls think of the process, try it out.
> 
> If I understand correctly, the motivation for moving the spec
> somewhere else is to replace the email patch review process with a git
> forge review process?

wait who said that?

-- 
MST

Re: Where should the vhost-user specification live?

[Albert Esteve]

On Mon, Jun 1, 2026 at 3:51 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > > > >  But also because, in my opinion, separating
> > > > > the specification would improve development agility by decoupling
> > > > > specification development from QEMU's review and release cycles.
> > > >
> > > > Generally for QEMU this will be less agility, unless I misunderstand
> > > > what is proposed)
> > > >
> > > > Because presumably there will need to be spec releases then?
> > > >
> > > > So
> > > >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> > > >
> > > > is surely longer that what we have now.
> > >
> > > I see your point.
> > >
> > > However, we do not really need to introduce a heavy release management
> > > layer. We could just operate it as a living document, where the main
> > > branch is the authoritative source of truth.
> > >
> > > For the workflow, development doesn't have to be strictly sequential
> > > either. A contributor can propose the spec update while working on the
> > > implementation, much like we do for VirtIO updates. Actually, this way
> > > one update/change supports the other.
> > >
> > > I guess my point is that a dedicated repository could lower the
> > > barrier for new changes AND keep QEMU's own development speed mostly
> > > unaffected.
> > >
> > > BR,
> > > Albert
> >
> > Something something submodule? Possibly. If you want to make progress
> > on this, pls think of the process, try it out.
>
> If I understand correctly, the motivation for moving the spec
> somewhere else is to replace the email patch review process with a git
> forge review process?
>
> This seems like a superficial change and is not worth in my opinion if
> you consider we'll have to redirect from the old spec location and
> move the community over to the new repo.

The core issue from my perspective is project neutrality and
decoupling lifecycles.

Currently, protocol updates are tied to QEMU's tree rules and release
freezes for example. Since these changes also affect other projects
(like rust-vmm, crosvm, DPDK, etc.), separating them may make sense
and could streamline the process.

>We could actually lose spec
> change reviewers in the process either because they don't know what's
> going on or decide that they prefer to spend time elsewhere when faced
> with switching processes (the people who review and participate in
> discussion do so out of personal interest and as far as I'm aware no
> one is employed to work on vhost-user as their #1 priority).

This is a fair concern. I hope we maintain reviewer engagement. But it
could also be argued that contributors from other communities may be
more comfortable with a dedicated project-neutral home. It could well
go both ways, but it also represents an opportunity to grow.

>
> Having said that, here is what I imagine it would involve:
>
> 1. Michael creates a new repo on a git forge (if he wants it to be
> under the GitLab qemu-project organization I can help with creating
> the repo, otherwise he creates a new organization and repo).
> 2. Discussion happens in Issues.
> 3. Spec changes are proposed in Merge Requests. Michael merges them
> once consensus has been reached.

Mostly yes, though we wouldn't necessarily need Michael as the sole
gatekeeper. We could invite co-maintainers from other key projects to
share the reviewer load.

Also I'd want to clarify that although I am advocating for this
change, I do not claim to have the definitive roadmap. I am just
sharing my view on why this could be a positive evolution. Consensus
may end up being to remain with the current status quo, or any of the
other options proposed by Alex.

>
> It's similar to what we have now in qemu.git, except that a git forge is used.
>
> Stefan
>

Re: Where should the vhost-user specification live?

[Michael S. Tsirkin]

On Mon, Jun 01, 2026 at 04:27:46PM +0200, Albert Esteve wrote:
> On Mon, Jun 1, 2026 at 3:51 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > > On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > > > > >  But also because, in my opinion, separating
> > > > > > the specification would improve development agility by decoupling
> > > > > > specification development from QEMU's review and release cycles.
> > > > >
> > > > > Generally for QEMU this will be less agility, unless I misunderstand
> > > > > what is proposed)
> > > > >
> > > > > Because presumably there will need to be spec releases then?
> > > > >
> > > > > So
> > > > >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> > > > >
> > > > > is surely longer that what we have now.
> > > >
> > > > I see your point.
> > > >
> > > > However, we do not really need to introduce a heavy release management
> > > > layer. We could just operate it as a living document, where the main
> > > > branch is the authoritative source of truth.
> > > >
> > > > For the workflow, development doesn't have to be strictly sequential
> > > > either. A contributor can propose the spec update while working on the
> > > > implementation, much like we do for VirtIO updates. Actually, this way
> > > > one update/change supports the other.
> > > >
> > > > I guess my point is that a dedicated repository could lower the
> > > > barrier for new changes AND keep QEMU's own development speed mostly
> > > > unaffected.
> > > >
> > > > BR,
> > > > Albert
> > >
> > > Something something submodule? Possibly. If you want to make progress
> > > on this, pls think of the process, try it out.
> >
> > If I understand correctly, the motivation for moving the spec
> > somewhere else is to replace the email patch review process with a git
> > forge review process?
> >
> > This seems like a superficial change and is not worth in my opinion if
> > you consider we'll have to redirect from the old spec location and
> > move the community over to the new repo.
> 
> The core issue from my perspective is project neutrality and
> decoupling lifecycles.


Then maybe we can keep the email based review? Still the only
one with a decent offline capability.


> Currently, protocol updates are tied to QEMU's tree rules and release
> freezes for example. Since these changes also affect other projects
> (like rust-vmm, crosvm, DPDK, etc.), separating them may make sense
> and could streamline the process.
> 
> >We could actually lose spec
> > change reviewers in the process either because they don't know what's
> > going on or decide that they prefer to spend time elsewhere when faced
> > with switching processes (the people who review and participate in
> > discussion do so out of personal interest and as far as I'm aware no
> > one is employed to work on vhost-user as their #1 priority).
> 
> This is a fair concern. I hope we maintain reviewer engagement. But it
> could also be argued that contributors from other communities may be
> more comfortable with a dedicated project-neutral home. It could well
> go both ways, but it also represents an opportunity to grow.
> 
> >
> > Having said that, here is what I imagine it would involve:
> >
> > 1. Michael creates a new repo on a git forge (if he wants it to be
> > under the GitLab qemu-project organization I can help with creating
> > the repo, otherwise he creates a new organization and repo).
> > 2. Discussion happens in Issues.
> > 3. Spec changes are proposed in Merge Requests. Michael merges them
> > once consensus has been reached.
> 
> Mostly yes, though we wouldn't necessarily need Michael as the sole
> gatekeeper. We could invite co-maintainers from other key projects to
> share the reviewer load.
> 
> Also I'd want to clarify that although I am advocating for this
> change, I do not claim to have the definitive roadmap. I am just
> sharing my view on why this could be a positive evolution. Consensus
> may end up being to remain with the current status quo, or any of the
> other options proposed by Alex.

> >
> > It's similar to what we have now in qemu.git, except that a git forge is used.
> >
> > Stefan
> >

Re: Where should the vhost-user specification live?

[Stefan Hajnoczi]

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

On Mon, Jun 01, 2026 at 04:27:46PM +0200, Albert Esteve wrote:
> On Mon, Jun 1, 2026 at 3:51 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > > On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > > > > >  But also because, in my opinion, separating
> > > > > > the specification would improve development agility by decoupling
> > > > > > specification development from QEMU's review and release cycles.
> > > > >
> > > > > Generally for QEMU this will be less agility, unless I misunderstand
> > > > > what is proposed)
> > > > >
> > > > > Because presumably there will need to be spec releases then?
> > > > >
> > > > > So
> > > > >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> > > > >
> > > > > is surely longer that what we have now.
> > > >
> > > > I see your point.
> > > >
> > > > However, we do not really need to introduce a heavy release management
> > > > layer. We could just operate it as a living document, where the main
> > > > branch is the authoritative source of truth.
> > > >
> > > > For the workflow, development doesn't have to be strictly sequential
> > > > either. A contributor can propose the spec update while working on the
> > > > implementation, much like we do for VirtIO updates. Actually, this way
> > > > one update/change supports the other.
> > > >
> > > > I guess my point is that a dedicated repository could lower the
> > > > barrier for new changes AND keep QEMU's own development speed mostly
> > > > unaffected.
> > > >
> > > > BR,
> > > > Albert
> > >
> > > Something something submodule? Possibly. If you want to make progress
> > > on this, pls think of the process, try it out.
> >
> > If I understand correctly, the motivation for moving the spec
> > somewhere else is to replace the email patch review process with a git
> > forge review process?
> >
> > This seems like a superficial change and is not worth in my opinion if
> > you consider we'll have to redirect from the old spec location and
> > move the community over to the new repo.
> 
> The core issue from my perspective is project neutrality and
> decoupling lifecycles.
>
> Currently, protocol updates are tied to QEMU's tree rules and release
> freezes for example. Since these changes also affect other projects
> (like rust-vmm, crosvm, DPDK, etc.), separating them may make sense
> and could streamline the process.

I don't see a reason to block vhost-user.rst changes during QEMU's
freeze. If Michael sent a vhost-user spec pull request during freeze I
would merge it.

> >We could actually lose spec
> > change reviewers in the process either because they don't know what's
> > going on or decide that they prefer to spend time elsewhere when faced
> > with switching processes (the people who review and participate in
> > discussion do so out of personal interest and as far as I'm aware no
> > one is employed to work on vhost-user as their #1 priority).
> 
> This is a fair concern. I hope we maintain reviewer engagement. But it
> could also be argued that contributors from other communities may be
> more comfortable with a dedicated project-neutral home. It could well
> go both ways, but it also represents an opportunity to grow.
> 
> >
> > Having said that, here is what I imagine it would involve:
> >
> > 1. Michael creates a new repo on a git forge (if he wants it to be
> > under the GitLab qemu-project organization I can help with creating
> > the repo, otherwise he creates a new organization and repo).
> > 2. Discussion happens in Issues.
> > 3. Spec changes are proposed in Merge Requests. Michael merges them
> > once consensus has been reached.
> 
> Mostly yes, though we wouldn't necessarily need Michael as the sole
> gatekeeper. We could invite co-maintainers from other key projects to
> share the reviewer load.
>
> Also I'd want to clarify that although I am advocating for this
> change, I do not claim to have the definitive roadmap. I am just
> sharing my view on why this could be a positive evolution. Consensus
> may end up being to remain with the current status quo, or any of the
> other options proposed by Alex.

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?

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.

Why is the current system not neutral and how will the new system solve
that?

Who should be a co-maintainer?

Stefan

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

Re: Where should the vhost-user specification live?

[Stefan Hajnoczi]

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

On Mon, Jun 01, 2026 at 10:22:32AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2026 at 09:51:40AM -0400, Stefan Hajnoczi wrote:
> > On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > > On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > > > > >  But also because, in my opinion, separating
> > > > > > the specification would improve development agility by decoupling
> > > > > > specification development from QEMU's review and release cycles.
> > > > >
> > > > > Generally for QEMU this will be less agility, unless I misunderstand
> > > > > what is proposed)
> > > > >
> > > > > Because presumably there will need to be spec releases then?
> > > > >
> > > > > So
> > > > >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> > > > >
> > > > > is surely longer that what we have now.
> > > >
> > > > I see your point.
> > > >
> > > > However, we do not really need to introduce a heavy release management
> > > > layer. We could just operate it as a living document, where the main
> > > > branch is the authoritative source of truth.
> > > >
> > > > For the workflow, development doesn't have to be strictly sequential
> > > > either. A contributor can propose the spec update while working on the
> > > > implementation, much like we do for VirtIO updates. Actually, this way
> > > > one update/change supports the other.
> > > >
> > > > I guess my point is that a dedicated repository could lower the
> > > > barrier for new changes AND keep QEMU's own development speed mostly
> > > > unaffected.
> > > >
> > > > BR,
> > > > Albert
> > >
> > > Something something submodule? Possibly. If you want to make progress
> > > on this, pls think of the process, try it out.
> > 
> > If I understand correctly, the motivation for moving the spec
> > somewhere else is to replace the email patch review process with a git
> > forge review process?
> 
> wait who said that?

I thought that's what the issue ultimately comes down to but it's clear
now that's not it.

Stefan

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

Re: Where should the vhost-user specification live?

[Michael S. Tsirkin]

On Mon, Jun 01, 2026 at 11:18:15AM -0400, Stefan Hajnoczi wrote:
> On Mon, Jun 01, 2026 at 04:27:46PM +0200, Albert Esteve wrote:
> > On Mon, Jun 1, 2026 at 3:51 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > >
> > > On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > > > On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > >
> > > > > > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > > > > > >  But also because, in my opinion, separating
> > > > > > > the specification would improve development agility by decoupling
> > > > > > > specification development from QEMU's review and release cycles.
> > > > > >
> > > > > > Generally for QEMU this will be less agility, unless I misunderstand
> > > > > > what is proposed)
> > > > > >
> > > > > > Because presumably there will need to be spec releases then?
> > > > > >
> > > > > > So
> > > > > >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> > > > > >
> > > > > > is surely longer that what we have now.
> > > > >
> > > > > I see your point.
> > > > >
> > > > > However, we do not really need to introduce a heavy release management
> > > > > layer. We could just operate it as a living document, where the main
> > > > > branch is the authoritative source of truth.
> > > > >
> > > > > For the workflow, development doesn't have to be strictly sequential
> > > > > either. A contributor can propose the spec update while working on the
> > > > > implementation, much like we do for VirtIO updates. Actually, this way
> > > > > one update/change supports the other.
> > > > >
> > > > > I guess my point is that a dedicated repository could lower the
> > > > > barrier for new changes AND keep QEMU's own development speed mostly
> > > > > unaffected.
> > > > >
> > > > > BR,
> > > > > Albert
> > > >
> > > > Something something submodule? Possibly. If you want to make progress
> > > > on this, pls think of the process, try it out.
> > >
> > > If I understand correctly, the motivation for moving the spec
> > > somewhere else is to replace the email patch review process with a git
> > > forge review process?
> > >
> > > This seems like a superficial change and is not worth in my opinion if
> > > you consider we'll have to redirect from the old spec location and
> > > move the community over to the new repo.
> > 
> > The core issue from my perspective is project neutrality and
> > decoupling lifecycles.
> >
> > Currently, protocol updates are tied to QEMU's tree rules and release
> > freezes for example. Since these changes also affect other projects
> > (like rust-vmm, crosvm, DPDK, etc.), separating them may make sense
> > and could streamline the process.
> 
> I don't see a reason to block vhost-user.rst changes during QEMU's
> freeze. If Michael sent a vhost-user spec pull request during freeze I
> would merge it.
> 
> > >We could actually lose spec
> > > change reviewers in the process either because they don't know what's
> > > going on or decide that they prefer to spend time elsewhere when faced
> > > with switching processes (the people who review and participate in
> > > discussion do so out of personal interest and as far as I'm aware no
> > > one is employed to work on vhost-user as their #1 priority).
> > 
> > This is a fair concern. I hope we maintain reviewer engagement. But it
> > could also be argued that contributors from other communities may be
> > more comfortable with a dedicated project-neutral home. It could well
> > go both ways, but it also represents an opportunity to grow.
> > 
> > >
> > > Having said that, here is what I imagine it would involve:
> > >
> > > 1. Michael creates a new repo on a git forge (if he wants it to be
> > > under the GitLab qemu-project organization I can help with creating
> > > the repo, otherwise he creates a new organization and repo).
> > > 2. Discussion happens in Issues.
> > > 3. Spec changes are proposed in Merge Requests. Michael merges them
> > > once consensus has been reached.
> > 
> > Mostly yes, though we wouldn't necessarily need Michael as the sole
> > gatekeeper. We could invite co-maintainers from other key projects to
> > share the reviewer load.
> >
> > Also I'd want to clarify that although I am advocating for this
> > change, I do not claim to have the definitive roadmap. I am just
> > sharing my view on why this could be a positive evolution. Consensus
> > may end up being to remain with the current status quo, or any of the
> > other options proposed by Alex.
> 
> 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?
> 
> 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.
> 
> Why is the current system not neutral and how will the new system solve
> that?
> 
> Who should be a co-maintainer?
> 
> Stefan

And also, qemu currently acts like a reference implementation.
Which is something.

-- 
MST

Re: Where should the vhost-user specification live?

[Stefan Hajnoczi]

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