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

Demi Marie Obenour
2026-02-24T17:57:33Z

[-- Attachment #1.1.1: Type: text/plain, Size: 3623 bytes --]

On 1/26/26 11:32, Bill Mills wrote:
> 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.
>
> We are working on a few reusable bus implementations:
>
> * virtio-msg-ffa based on Arm FF-A interface for use between:
> * normal world and secure world
> * host and VM or VM to VM
> * Can be used w/ or with out a hypervisor
> * Any Hypervisor that implements FF-A can be used
> * We have this working with pKVM and Xen
> * We have this working with Trusty and OP-TEE
>
> * virtio-msg-amp for use between heterogenous systems
> * The main processors and its co-processors on an AMP SOC
> * Two or more systems connected via PCIe
> * Minimal requirements: bi-directional interrupts and
> at least one shared memory area
> * hvac-demo has 2 demos of this
> * This is working on two hardware platforms
>
> * virtio-msg-loopback for userspace implemented devices
> * Allows user space to provide devices to its own kernel
> * This is similar to fuse, cuse or loopback block devices but for virtio
> * hvac-demo has a demo
>
> We also anticipate a few more:
>
> * virtio-msg-xen specific to Xen
> * Usable on any Xen system (including x86 where FF-A does not exist)
> * Using Xen events and page grants
>
> * virtio-msg over admin virtqueues
> * This allows any virtio-pci device that supports admin virtqueues to also
> support a virtio-msg bus that supports sub devices
> * [We are looking for collaborators for this work]

Which transport, if any, would be suitable for communication
between a KVM VM and a userspace process or between two KVM VMs?
Would this require a new bus? If so, should it be implemented in
terms of vhost-user?
--
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]