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

Demi Marie Obenour <[email protected]> Wed, 25 Feb 2026 10:46:04 -0500
Newsgroups	dev.linux.lists.virtio-comment
Message-ID	<[email protected]>
On 2/25/26 10:21, Alex Bennée wrote:
> Demi Marie Obenour <[email protected]> writes:
> 
>> 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
> 
> I think vhost-user already covers this case well enough. However there
> is no reason the VMM could terminate a virtio-msg bus and pass the
> messages across vhost-user to a device backend. 

Does this provide any advantages over the existing virtio-PCI
transport?

>> or between two KVM VMs?
>> Would this require a new bus?  If so, should it be implemented in
>> terms of vhost-user?
> 
> If you want the backend for a VirtIO device in another KVM VM that I
> suspect you want to avoid a round-trip through the user-space of the
> VMM. If FF-A isn't an option the hypervisor could support some sort of
> minimal hypercall transport to pass messages between the two.

My plan was to use irqfd + ioeventfd + shared memory to avoid
round-trips through userspace in the data path.  That's not a good
fit for any of the proposed transports, though.

Do you have suggestions for how to implement a virtio device in another
KVM VM?  I'd prefer to not need to patch KVM itself unless it provides
a big advantage of some sort.

I know that virtio-vhost-user already exists, but am not sure if
something based on virtio-msg would be a better option.  Specifically,
there could be a virtio device that passed driver-to-device messages
to the backend VM, and passed device-to-driver messages to the
frontend VMM.  If you think that there is an even better option,
I would greatly appreciate the suggestion.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc (application/pgp-keys, 7 KB)
OpenPGP_signature.asc (application/pgp-signature, 833 B)