Re: [PATCH] Reserve device ID 51 for Virtio HAB (Host-Guest Auxiliary Bridge) device

Albert Esteve <[email protected]> Mon, 3 Aug 2026 11:37:26 +0200
Newsgroups dev.linux.lists.virtio-comment
Message-ID <CADSE00KHLXywjkJJ5fzJPcgTeAz9k3_pq9+7+WV43a+yosDXmw@mail.gmail.com>
On Fri, Jul 17, 2026 at 6:10=E2=80=AFPM Zelong Ren <[email protected]=
m> wrote:
>
> Hi all,
>
> Gentle ping on this patch.
>
> The earlier questions have been addressed in the thread. Could anyone com=
ment
> on whether there are any remaining concerns with reserving Device ID 51 f=
or
> Virtio HAB?

Hi,

If there are no concerns raised for a period of time, the next step
would be to open an Issue in the repository (which you already did),
and request a TC voting as specified in [1].

BR,
Albert.

[1] https://github.com/oasis-tcs/virtio-spec#use-of-github-issues

>
> I'd be happy to provide additional details if needed.
>
> Thanks for your review.
>
> Best regards,
> Zelong
>
> On Mon, 7 Jul 2026, Zelong Ren wrote:
> >
> > > Can this be used for communication between two different guest VMs?
> >
> > We didn't have this use case today but with some effort this can be sup=
ported.
> > It should be viewed as 2 GVMs still requires the setup of PVM and assis=
tance
> > of it to reach this functionality.
> >
> > > Do you plan to upstream the specification for this device as well?
> >
> > Yes, agree 100%.
> > The ID reservation is the first step, we plan to upstream the device sp=
ecification
> > to the virtio TC as well.
> >
> > On Thu, 2 Jul 2026, Demi Marie Obenour wrote:
> > >
> > > > Virtio HAB device is an inter-VM IPC and shared-memory device
> > > > intended for multi-VM systems.
> > > >
> > > > Virtio HAB provides named service channels between guest VMs
> > > > and primary/service VM, primarily targeting platform-specific
> > > > hardware accelerators and system services (deployed in Qualcomm
> > > > automotive platforms).
> > >
> > > Can this be used for communication between two different guest VMs?
> > >
> > > > It also supports bi-directional zero-copy shared-memory lifecycle
> > > > operations (export/unexport/import/unimport).
> > > >
> > > > The driver is shipping in Qualcomm automotive IVI products,
> > > > supports Gunyah, QNX, Green Hills, Red Bend and Xen hypervisors
> > > > (KVM in progress), and is being prepared for Linux kernel upstreami=
ng.
> > > >
> > > > Signed-off-by: Zelong Ren <[email protected]>
> > > > ---
> > > >  content.tex | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/content.tex b/content.tex
> > > > index 243ce2d..25837d8 100644
> > > > --- a/content.tex
> > > > +++ b/content.tex
> > > > @@ -805,6 +805,8 @@ \chapter{Device Types}\label{sec:Device Types}
> > > >  \hline
> > > >  50         &   Video encoder/decoder device \\
> > > >  \hline
> > > > +51         &   HAB (Host-Guest Auxiliary Bridge) device \\
> > > > +\hline
> > > >  \end{longtable}
> > > >
> > > >  Some of the devices above are unspecified by this document,
> > >
> > > Do you plan to upstream the specification for this device as well?
>