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)