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

["Alex Bennée" <alex.bennee@linaro.org>]

Demi Marie Obenour <demiobenour@gmail.com> 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. 

> 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.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro