[PATCH RFC v2 00/11] remoteproc: add support for any virtio device
Francesco Valla
francesco at valla.it
Sun Nov 1 15:26:37 PST 2026
Hello,
this is the second iteration of the patch series that introduces the
possibility to support generic virtio devices over the remoteproc
transport, whereas today only rpmsg and rproc-serial are supported.
Some introduction and motivation can be found in V1 [1].
This new proposal leverages the existing virtio infrastructure and its
optional usage of the DMA APIs to obtain the goal in two cases:
- if the remote device is able to access the whole DMA space of the
host, no special arrangement is needed; the DMA APIs will take care
of cache management and (if required) DMA translation, optionally
resorting to swiotlb if/when the buffers allocated by a virtio driver
are not DMA-able;
- in case the remote device and the host share only a small portion of
memory (often the case for e.g. mixed-criticality systems), the DMA
APIs can be coupled with a restricted-dma-pool area to force swiotlb
translation for all the transmitted buffers.
The new functionality is introduced by setting the
VIRTIO_F_ACCESS_PLATFORM feature flag for all non-remoteproc-specific
virtio devices (i.e., all except the aforementioned rpmsg and
rproc-serial); this flag instructs the virtio framework to use the DMA
APIs when mapping and unmapping buffers to and from the remote
processor.
The series was tested against a custom Zephyr application [2] running on
the Cortex-M33 processor of an i.MX93 and exposing six different virtio
devices:
- rpmsg
- entropy (rng)
- gpio
- i2c
- spi
- can
== Open Points ==
There are still the following open points:
- some virtio devices (e.g.: virtio-input) communicate through the
device's config space. The remoteproc transport expects this config
space to be somewhat constant, and there is no mechanism to sync
changes made by the driver with the remote device.
- device de-registration on remoteproc stop is causing oopses (under
investigation - might not be strictly tied to the series).
- I still have to wrap my mind around DMA ranges and IOMMUs, and the
way the remoteproc framework uses them; the current series keeps the
legacy behavior for the first (i.e., DMA properties of the parent
remoteproc device are copied to vdevs) and assumes da == pa for
remote processor behind an IOMMU.
- [i.MX-specific] the imx-rproc driver was sending messages in
blocking mode; the change proposed in the series, required for
proper operation in atomi contexts is sub-optimal and needs more
work.
== Patches breakdown ==
Patches 1 and 2 are cleanups to the remoteproc-virtio driver and could
be applied independently of this series.
Patch 3 was submitted a couple of months ago [6] and paves the road for
the actual support of generic virtio devices, removing the fixed number
of 2 for the vrings associated to a vdev.
Patch 4 defines the VIRTIO_F_VERSION_1 feature for all
non-rproc-specific vdevs. This is required to support some virtio device
types, and there is no other mean of defining it, since the field
reserved for features inside the resource table is limited to 32 bits.
Given that the 1.x virtio specifications are ~10 years old this still
seems reasonable.
Patch 5 defines the VIRTIO_F_ACCESS_PLATFORM feature for all
non-rproc-specific vdevs. This is the first step required to obtain the
full virtio functionality.
Patch 6 introduces new devicetree bindings for declaring virtio
devices exposed by a remote processor inside a devicetree. This is not
required for some devices (e.g.: can, net, gpu), but for others (e.g.:
i2c, gpio) is necessary to declare child devices and link them.
Patch 7 assigns a fwnode (if existent) to each new virtio device and
assigns to it the memory region defined for such node.
Patch 8 expands existing remoteproc-virtio documentation to explain the
possibilities introduced by the previous changes.
Patches 9 and 10 are i.MX-specific and enable the usage of the newly
introduced support on this family of platforms. The first one might
probably be submitted independently of the series, since it aligns
the behavior of imx-rproc to the other platforms in relation to
mailbox usage. However, having a kmalloc in the hot send path is
sub-optimal. **Advice needed here.**
Finally, patch 11 is the PoC that has been used to develop and test the
series and shall not be merged.
======
Thanks to everyone that commented on v1 - the functionality evolved in a
much more flexible and no-nonsense way. Thanks in advance to whom will
do the same on this revision.
Regards,
Francesco
[1] https://patch.msgid.link/20260916-remoteproc_virtio_map-v1-0-dac8c5eb4aa9@valla.it
[2] https://github.com/WallaceIT/zephyr/tree/multi_vdev
---
Changes in v2:
- Rebased on v7.4-rc1
- Drop the custom .map APIs and rely on the virtio framework to perform
DMA management and (if required) the bounce buffering [Robin].
- Set the VERSION_1 and ACCESS_PLATFORM features only for
non-rproc-specific virtio devices to preserve existing usecases.
- Add the possibility to have a memory-region property in each vdev's
node and use it for DMA allocations / swiotlb.
- Drop the new DMA subsystem APIs (no more required).
- Drop the spi-virtio bindings, which are not critical for the series
and have been submitted independently [Mathieu].
- PoC i.MX93 FRDM dts: drop the virtio/spi node and child devices and
move from gpio-keys-polled to gpio-keys.
- Re-introduced the rsc-table in PoC i.MX93 FRDM dts.
- Fixes in the remoteproc-virtio bindings [Rob].
- imx-rproc: drop unneeded rework of reserved memory assignment.
- imx-rproc: do not send async mailbox messages with payload living in
the stack.
- Rephrase and expand commit messages.
- Document the memory allocation behavior.
- Scattered fixes for minor issues [Mathieu and sashiko].
- Link to v1: https://patch.msgid.link/20260916-remoteproc_virtio_map-v1-0-dac8c5eb4aa9@valla.it
To: Bjorn Andersson <andersson at kernel.org>
To: Mathieu Poirier <mathieu.poirier at linaro.org>
To: Kees Cook <kees at kernel.org>
To: "Gustavo A. R. Silva" <gustavoars at kernel.org>
To: Rob Herring <robh at kernel.org>
To: Krzysztof Kozlowski <krzk+dt at kernel.org>
To: Conor Dooley <conor+dt at kernel.org>
To: Francesco Valla <francesco at valla.it>
To: Jonathan Corbet <corbet at lwn.net>
To: Shuah Khan <skhan at linuxfoundation.org>
To: Randy Dunlap <rdunlap at infradead.org>
To: Frank Li <Frank.Li at nxp.com>
To: Sascha Hauer <s.hauer at pengutronix.de>
To: Pengutronix Kernel Team <kernel at pengutronix.de>
To: Fabio Estevam <festevam at gmail.com>
To: Peng Fan <peng.fan at nxp.com>
Cc: Robin Murphy <robin.murphy at arm.com>
Cc: linux-remoteproc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-hardening at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: imx at lists.linux.dev
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Francesco Valla <francesco at valla.it>
---
Francesco Valla (11):
remoteproc: virtio: cleanup rproc_add_virtio_dev error path
remoteproc: virtio: replace commas with semicolons
remoteproc: virtio: support dynamic number of vrings
remoteproc: report VIRTIO_F_VERSION_1 for non-rproc-specific vdevs
remoteproc: virtio: report VIRTIO_F_ACCESS_PLATFORM when required
dt-bindings: remoteproc: add remoteproc-virtio
remoteproc: assign fwnode during vdev registration
Documentation: remoteproc: expand virtio support section
remoteproc: imx_rproc: always use non-blocking mailboxes
dt-bindings: remoteproc: imx-rproc: support virtio
PoC: arm64: dts: imx93-11x11-frdm: add multiple vdevs
.../bindings/remoteproc/fsl,imx-rproc.yaml | 3 +-
.../bindings/remoteproc/remoteproc-virtio.yaml | 106 ++++++++++++
Documentation/staging/remoteproc.rst | 99 ++++++++++-
arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts | 188 +++++++++++++++++++++
drivers/remoteproc/imx_rproc.c | 76 +++------
drivers/remoteproc/imx_rproc.h | 1 -
drivers/remoteproc/remoteproc_core.c | 55 ++++--
drivers/remoteproc/remoteproc_virtio.c | 110 +++++++++---
include/linux/remoteproc.h | 10 +-
9 files changed, 558 insertions(+), 90 deletions(-)
---
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
change-id: 20260915-remoteproc_virtio_map-bcf32a5fab54
Best regards,
--
Francesco Valla <francesco at valla.it>
More information about the linux-arm-kernel
mailing list