Re: [PATCH v1 0/4] virtio-msg transport layer

Armelle Laine <[email protected]> Thu, 19 Feb 2026 09:31:09 -0800
Newsgroups dev.linux.lists.virtio-comment
Message-ID <CAAy_87-R3wF1FrCAe2P4i5gNwmVKeJv0L558vBb+X3yZRnR=bw@mail.gmail.com>
Hi everyone,

We are planning to release virtio-msg over FFA for Android Virtualization
Framework (AVF) pVM to TrustZone communication in the next Android release.
The Guest OS is Trusty OS, and the virtio-vsock over virtio-msg over FFA
driver/device support will be upstreamed to AOSP at the time of the release.

Acked-by: Armelle Laine [email protected]

Thanks,
Armelle

On Fri, Feb 13, 2026 at 11:45 AM Demi Marie Obenour <[email protected]>
wrote:

> On 2/13/26 08:52, Parav Pandit wrote:
> > Hi Bill,
> >
> >> From: Bill Mills <[email protected]>
> >> Sent: 26 January 2026 10:02 PM
> >>
> >> This series adds the virtio-msg transport layer.
> >>
> >> The individuals and organizations involved in this effort have had
> difficulty in
> >> using the existing virtio-transports in various situations and desire
> to add one
> >> more transport that performs its transport layer operations by sending
> and
> >> receiving messages.
> >>
> >> Implementations of virtio-msg will normally be done in multiple layers:
> >> * common / device level
> >> * bus level
> >>
> >> The common / device level defines the messages exchanged between the
> driver
> >> and a device. This common part should lead to a common driver holding
> most
> >> of the virtio specifics and can be shared by all virtio-msg bus
> implementations.
> >> The kernel implementation in [3] shows this separation. As with other
> transport
> >> layers, virtio-msg should not require modifications to existing virtio
> device
> >> implementations (virtio-net, virtio-blk etc). The common / device level
> is the
> >> main focus of this version of the patch series.
> >>
> >> The virtio-msg bus level implements the normal things a bus defines
> >> (enumeration, dma operations, etc) but also implements the message send
> and
> >> receive operations. A number of bus implementations are envisioned,
> >> some of which will be reusable and general purpose. Other bus
> implementations
> >> might be unique to a given situation, for example only used by a PCIe
> card
> >> and its driver.
> >>
> >> The standard bus messages are an effort to avoid different bus
> implementations
> >> doing the same thing in different ways for no good reason. However the
> >> different environments will require different things. Instead of trying
> to
> >> anticipate all needs and provide something very abstract, we think
> >> implementation specific messages will be needed at the bus level. Over
> time,
> >> if we see similar messages across multiple bus implementations, we will
> move to
> >> standardize a bus level message for that.
> >>
> >
> > I would review more, had first round of sparse review.
> > Please find few comments/questions below.
> >
> > 1. device number should be 32-bit in struct virtio_msg_header.
> > From SIOV_R2 experiences, we learnt that some uses have use case for
> more than 64k devices.
> > Also mapping PCI BDF wont be enough in 16-bits considering domain field.
>
> I recommend using a 64-bit or even 128-bit number.  This allows
> ensuring that device IDs are unique for the life of a VM or even
> globally, making reasoning about device identity simpler.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)