Hello,

This RFC series introduces support for a new Virtio transport type:
"virtio-msg", as proposed in [1]. Unlike existing transport types like
virtio-mmio or virtio-pci, which rely on memory-mapped registers, virtio-msg
implements transport operations via structured messages. Those messages can be
transported through different mechanisms such as mailboxes, shared memory based
FIFO or specific protocols such as FF-A on Arm.

This series includes:
- Core virtio-msg transport support.
- Two message transport bus implementations:
  - virtio-msg-ffa: based on ARM's Firmware Framework for Arm (FF-A).
  - virtio-msg-loopback: a loopback device for testing and validation.

The code is available here for reference: [2] and virtio-msg loopback and FF-A
test setups are explained here: [3] and [4].

This series is based on v6.16 and depends on commit [5].


### Memory Mapping and Reserved Memory Usage

The first two patches enhance the reserved-memory subsystem to support attaching
struct device`s that do not originate from DT nodes — essential for virtual or
dynamically discovered devices like the FF-A or loopback buses.

This reserved-memory region enables:
- Restricting all DMA-coherent and streaming DMA memory to a controlled range.
- Allowing the remote endpoint to pre-map this memory, reducing runtime overhead.
- Preventing unintentional data leaks, since memory is typically shared at page
  granularity.
- For the loopback bus, it restricts the portion of kernel memory that can be
  mapped into userspace, improving safety.

Device association with reserved-memory regions is based on DT node naming
conventions, such as vmsglb@ or vmsgffa@, similar to the remoteproc framework’s
approach.

Feedback on the design, API, and approach is welcome.

--
Viresh

[1] https://lore.kernel.org/all/20250620224426.3923880-2-bill.mills@linaro.org/
[2] git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git virtio/msg-rfc-v1
[3] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/30104092673
[4] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/29657792513
[5] From linux-next: 5be53630b4f0 virtio-mmio: Remove virtqueue list from mmio device


Viresh Kumar (6):
  of: reserved-memory: Add reserved_mem_device_init()
  of: reserved-memory: Add of_reserved_mem_lookup_by_name
  virtio: Add support for virtio-msg transport
  virtio-msg: Add optional userspace interface for message I/O
  virtio-msg: Add support for FF-A (Firmware Framework for Arm) bus
  virtio-msg: Add support for loopback bus

 MAINTAINERS                          |   7 +
 drivers/of/of_reserved_mem.c         |  91 +++-
 drivers/virtio/Kconfig               |  34 ++
 drivers/virtio/Makefile              |   5 +
 drivers/virtio/virtio_msg.c          | 655 +++++++++++++++++++++++++++
 drivers/virtio/virtio_msg_ffa.c      | 505 +++++++++++++++++++++
 drivers/virtio/virtio_msg_internal.h |  88 ++++
 drivers/virtio/virtio_msg_loopback.c | 323 +++++++++++++
 drivers/virtio/virtio_msg_user.c     | 140 ++++++
 include/linux/of_reserved_mem.h      |  13 +
 include/uapi/linux/virtio_msg.h      | 213 +++++++++
 include/uapi/linux/virtio_msg_ffa.h  |  94 ++++
 include/uapi/linux/virtio_msg_lb.h   |  22 +
 13 files changed, 2166 insertions(+), 24 deletions(-)
 create mode 100644 drivers/virtio/virtio_msg.c
 create mode 100644 drivers/virtio/virtio_msg_ffa.c
 create mode 100644 drivers/virtio/virtio_msg_internal.h
 create mode 100644 drivers/virtio/virtio_msg_loopback.c
 create mode 100644 drivers/virtio/virtio_msg_user.c
 create mode 100644 include/uapi/linux/virtio_msg.h
 create mode 100644 include/uapi/linux/virtio_msg_ffa.h
 create mode 100644 include/uapi/linux/virtio_msg_lb.h

-- 
2.31.1.272.g89b43f80a514

On Wed, Jul 30, 2025 at 4:29 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> Hello,
>
> This RFC series introduces support for a new Virtio transport type:
> "virtio-msg", as proposed in [1]. Unlike existing transport types like
> virtio-mmio or virtio-pci, which rely on memory-mapped registers, virtio-msg
> implements transport operations via structured messages. Those messages can be
> transported through different mechanisms such as mailboxes, shared memory based
> FIFO or specific protocols such as FF-A on Arm.
>
> This series includes:
> - Core virtio-msg transport support.
> - Two message transport bus implementations:
>   - virtio-msg-ffa: based on ARM's Firmware Framework for Arm (FF-A).
>   - virtio-msg-loopback: a loopback device for testing and validation.
>
> The code is available here for reference: [2] and virtio-msg loopback and FF-A
> test setups are explained here: [3] and [4].
>
> This series is based on v6.16 and depends on commit [5].
>
>
> ### Memory Mapping and Reserved Memory Usage
>
> The first two patches enhance the reserved-memory subsystem to support attaching
> struct device`s that do not originate from DT nodes — essential for virtual or
> dynamically discovered devices like the FF-A or loopback buses.

We support creating devices from reserved-memory nodes. Just add a
compatible which you should do anyways because node names are not
supposed to be that specific or an ABI.

Rob

Hi Rob,

On 30-07-25, 08:39, Rob Herring wrote:
> On Wed, Jul 30, 2025 at 4:29 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > ### Memory Mapping and Reserved Memory Usage
> >
> > The first two patches enhance the reserved-memory subsystem to support attaching
> > struct device`s that do not originate from DT nodes — essential for virtual or
> > dynamically discovered devices like the FF-A or loopback buses.
> 
> We support creating devices from reserved-memory nodes.

I didn't know about this.

> Just add a
> compatible which you should do anyways because node names are not
> supposed to be that specific or an ABI.

Yeah, I already knew that the node-names thing isn't going to fly as
you and Krzysztof rightly pointed out. I just wanted inputs from you
guys and so did that as a first implementation to get the discussion
started.

I tried something like this now:

      reserved-memory {
        #address-cells = <2>;
        #size-cells   = <2>;
        ranges;

        rmem@100000000 {
          compatible = "restricted-dma-pool", "virtio-msg,loopback";
          reg = <0x00000001 0x00000000  0x0 0x00400000>; /* 4 MiB */
        };
      };

and this works fine. I am adding two compatibles for virtio-msg:
"virtio-msg,loopback" and "virtio-msg,ffa". Yes I will properly
document them in the next version.

With this, we don't need the 2nd patch anymore:
  of: reserved-memory: Add of_reserved_mem_lookup_by_name

but still need the 1st one:
  of: reserved-memory: Add reserved_mem_device_init()

Thanks.

-- 
viresh

On Tue, Aug 12, 2025 at 4:50 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> Hi Rob,
>
> On 30-07-25, 08:39, Rob Herring wrote:
> > On Wed, Jul 30, 2025 at 4:29 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > ### Memory Mapping and Reserved Memory Usage
> > >
> > > The first two patches enhance the reserved-memory subsystem to support attaching
> > > struct device`s that do not originate from DT nodes — essential for virtual or
> > > dynamically discovered devices like the FF-A or loopback buses.
> >
> > We support creating devices from reserved-memory nodes.
>
> I didn't know about this.
>
> > Just add a
> > compatible which you should do anyways because node names are not
> > supposed to be that specific or an ABI.
>
> Yeah, I already knew that the node-names thing isn't going to fly as
> you and Krzysztof rightly pointed out. I just wanted inputs from you
> guys and so did that as a first implementation to get the discussion
> started.
>
> I tried something like this now:
>
>       reserved-memory {
>         #address-cells = <2>;
>         #size-cells   = <2>;
>         ranges;
>
>         rmem@100000000 {
>           compatible = "restricted-dma-pool", "virtio-msg,loopback";

The order is wrong here. The 2nd one seems more specific to me. But is
"restricted-dma-pool" useful? Should an OS that only understands that
and not "virtio-msg,loopback" use it?

The format of compatibles is <vendor>,<device/block/interface> and
"virtio-msg" is not a vendor.

>           reg = <0x00000001 0x00000000  0x0 0x00400000>; /* 4 MiB */
>         };
>       };
>
> and this works fine. I am adding two compatibles for virtio-msg:
> "virtio-msg,loopback" and "virtio-msg,ffa". Yes I will properly
> document them in the next version.

Why do you need 2 compatibles? Can't you discover what the remote end
is with some message? We only define "virtio-mmio" in DT for example,
not that the device is a console, rng, etc.

Rob

On 12-08-25, 08:28, Rob Herring wrote:
> On Tue, Aug 12, 2025 at 4:50 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > I tried something like this now:
> >
> >       reserved-memory {
> >         #address-cells = <2>;
> >         #size-cells   = <2>;
> >         ranges;
> >
> >         rmem@100000000 {
> >           compatible = "restricted-dma-pool", "virtio-msg,loopback";
> 
> The order is wrong here. The 2nd one seems more specific to me.

Right.

> But is "restricted-dma-pool" useful?

I need this to call kernel/dma/swiotlb.c: rmem_swiotlb_setup(), which
makes all the memory allocation for the device happen from that area.

> Should an OS that only understands that and not
> "virtio-msg,loopback" use it?

Since the reserved memory isn't linked to a device in the DT (via the
"memory-region" property), I don't expect an OS to use it without
virtio-msg.

> The format of compatibles is <vendor>,<device/block/interface> and
> "virtio-msg" is not a vendor.

"virtio,msg" is fine then I guess ? Just like "virtio,mmio".

> >           reg = <0x00000001 0x00000000  0x0 0x00400000>; /* 4 MiB */
> >         };
> >       };
> >
> > and this works fine. I am adding two compatibles for virtio-msg:
> > "virtio-msg,loopback" and "virtio-msg,ffa". Yes I will properly
> > document them in the next version.
> 
> Why do you need 2 compatibles? Can't you discover what the remote end
> is with some message? We only define "virtio-mmio" in DT for example,
> not that the device is a console, rng, etc.

In case of virtio-mmio, the reg-range is trapped by the other side and
meaningful MMIO messages are exchanged. And so the OS knows the kind
of device the DT node is related to.

In this case however, this memory is going to be used for virtqueues
and buffers and I don't see a way of communicating the device type
here. Maybe I can get rid of two compatibles and add a property that
links to a device type ? The memory is otherwise exactly same in both
the cases, it is just about which device is using it eventually.

-- 
viresh