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

Hi Albert,

Thank you for the clarification.

Could the TC please open a voting ballot for reserving Device ID 51 for
Virtio HAB?

Fixes: https://github.com/oasis-tcs/virtio-spec/issues/249

Best regards,
Zelong

On Mon, Aug 3, 2026 at 5:37 PM Albert Esteve <[email protected]> wrote:
>
> On Fri, Jul 17, 2026 at 6:10 PM Zelong Ren <[email protected]> wrote:
> >
> > Hi all,
> >
> > Gentle ping on this patch.
> >
> > The earlier questions have been addressed in the thread. Could anyone comment
> > on whether there are any remaining concerns with reserving Device ID 51 for
> > 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 supported.
> > > It should be viewed as 2 GVMs still requires the setup of PVM and assistance
> > > 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 specification
> > > 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 upstreaming.
> > > > >
> > > > > 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?