[PATCH RFC v2 08/11] Documentation: remoteproc: expand virtio support section

[Francesco Valla]

Expand the section on virtio support over remoteproc with details on
memory allocation setup and constraints.

Signed-off-by: Francesco Valla <francesco at valla.it>
---
 Documentation/staging/remoteproc.rst | 99 +++++++++++++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 1 deletion(-)

diff --git a/Documentation/staging/remoteproc.rst b/Documentation/staging/remoteproc.rst
index c117b060e76c..4b42ed582fb4 100644
--- a/Documentation/staging/remoteproc.rst
+++ b/Documentation/staging/remoteproc.rst
@@ -354,7 +354,104 @@ it supports. A firmware may support any number of virtio devices, and
 of any type (a single remote processor can also easily support several
 rpmsg virtio devices this way, if desired).
 
+Memory carveouts
+----------------
+
+For a virtio device at position ``X`` among the RSC_VDEV resources declared by
+the resource table, the remoteproc framework will search for memory carveouts
+for:
+
+* all the vrings the specific virtio device requires (as ``vdevXvringY``);
+* the memory area to allocate communication buffers from (as ``vdevXbuffer``).
+
+The carveouts can be provided by the remote processor itself as RSC_CARVEOUT
+resources inside the resource table and/or supplied by the remoteproc driver
+and will be indexed by their name.
+If a carveout with the same name is provided through both means, the one
+supplied by the remote processor should be marked as dynamically allocable,
+i.e., with the device address set to ``FW_RSC_ADDR_ANY`` (-1).
+
+If a ``vdevXvringY`` carveout is not provided, the remoteproc framework will
+try to allocate it using dma_alloc_coherent(), which will resort to allocate it
+either from the first ``restricted-dma-pool`` region associated to the virtio
+device's parent (i.e., the remote processor device), if present, or the global
+DMA pool.
+
+.. WARNING::
+
+    This fallback mechanism can result in a vring being allocated using a
+    ``vdevXbuffer`` area meant for another vdev, so a particular care shall be
+    adopted when defining the carveouts. In particular, ``restricted-dma-pool``
+    memory regions should be specified inside the virtio device's devicetree
+    nodes and not attached to the parent remote processor.
+
+If a ``vdevXbuffer`` carveout is not provided, the remoteproc framework will
+use the memory region declared by the virtio device's own devicetree node (see
+Documentation/devicetree/bindings/remoteproc/remoteproc-virtio.yaml), if any.
+Otherwise, it will try to replace it with the first memory region (of any type)
+associated to the virtio device's parent (i.e., the remote processor device);
+if no such memory region is present, it will be replaced with the global DMA
+pool.
+
+If both a ``vdevXbuffer`` carveout and a memory region inside the virtio
+device's devicetree node are present, the carveout takes precedence and the
+memory region is ignored.
+
+Declaring the memory region inside the virtio device's devicetree node is the
+preferred method for ``restricted-dma-pool`` regions, since listing them among
+the memory regions of the remote processor device would make the first of them
+the (forced) bounce buffer for the remote processor device itself as well.
+
+Buffer allocation
+-----------------
+
+There are different kinds of buffer allocation scenarios:
+
+* if the remote processor can access the whole DMA memory area of the host, no
+  special arrangement needs to be performed, since either the drivers (in case
+  of rpmsg and rproc-serial devices) or the DMA APIs (in case of any other
+  virtio device type) will take care of any necessary translation;
+* if the remote processor has limited access to the host memory space, for
+  example because of a different addressing scheme or for memory isolation
+  constraints, the memory reserved for buffer allocation shall be selected
+  depending on the virtio device type:
+
+  - for rpmsg and rproc-serial devices, a simple contiguous memory region
+    (e.g.: one declared in devicetree as ``shared-dma-pool``) is sufficient and
+    should be preferred, since it allows zero-copy message transmission between
+    the host and the remote processor;
+  - for any other virtio device type, a swiotlb-enabled memory region (e.g.:
+    one declared in devicetree as ``restricted-dma-pool``) is required, because
+    such devices need bounce buffering to work correctly.
+
+For virtio devices other than rpmsg and rproc-serial, the remoteproc framework
+offers the ``VIRTIO_F_ACCESS_PLATFORM`` feature, so the buffer addresses written
+in the vring descriptors are the DMA addresses returned by the DMA APIs for the
+virtio device. The virtio device inherits the DMA mask and the DMA range map
+(i.e., the translation described by the ``dma-ranges`` devicetree property) of
+the remote processor device, and is never attached to an IOMMU: these DMA
+addresses are therefore host physical addresses, translated only through the
+DMA range map. The remote processor must be able to access the buffers at
+these addresses.
+
+.. WARNING::
+
+    For remote processors that access memory through an IOMMU managed by the
+    remoteproc framework (i.e., with ``has_iommu`` set), the IOMMU domain only
+    contains the mappings created for the RSC_CARVEOUT and RSC_DEVMEM entries
+    of the resource table, at the device addresses they specify; no mapping is
+    created for the buffers of the virtio devices. Such remote processors are
+    supported only if all the memory that can hold virtio buffers (e.g., the
+    ``restricted-dma-pool`` region associated to the virtio device) is mapped
+    with its device address equal to its physical address, for example through
+    an RSC_DEVMEM entry. The same constraint applies to any fixed address
+    translation applied by the remote processor that is not described by the
+    DMA range map of the remote processor device.
+
+Allocation of virtio devices
+----------------------------
+
 Of course, RSC_VDEV resource entries are only good enough for static
 allocation of virtio devices. Dynamic allocations will also be made possible
 using the rpmsg bus (similar to how we already do dynamic allocations of
-rpmsg channels; read more about it in rpmsg.txt).
+rpmsg channels; read more about it in Documentation/staging/rpmsg.rst).

-- 
2.56.0