On Tue, Jul 28, 2020 at 01:01:39PM +0800, Claire Chang wrote:
> Introduce the new compatible string, device-swiotlb-pool, for restricted
> DMA. One can specify the address and length of the device swiotlb memory
> region by device-swiotlb-pool in the device tree.
>
> Signed-off-by: Claire Chang <tien...@chromium.org>
> ---
> .../reserved-memory/reserved-memory.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index 4dd20de6977f..78850896e1d0 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -51,6 +51,24 @@ compatible (optional) - standard definition
> used as a shared pool of DMA buffers for a set of devices. It can
> be used by an operating system to instantiate the necessary pool
> management subsystem if necessary.
> + - device-swiotlb-pool: This indicates a region of memory meant to be
swiotlb is a Linux thing. The binding should be independent.
> + used as a pool of device swiotlb buffers for a given device. When
> + using this, the no-map and reusable properties must not be set, so
> the
> + operating system can create a virtual mapping that will be used for
> + synchronization. Also, there must be a restricted-dma property in
> the
> + device node to specify the indexes of reserved-memory nodes. One
> can
> + specify two reserved-memory nodes in the device tree. One with
> + shared-dma-pool to handle the coherent DMA buffer allocation, and
> + another one with device-swiotlb-pool for regular DMA to/from system
> + memory, which would be subject to bouncing. The main purpose for
> + restricted DMA is to mitigate the lack of DMA access control on
> + systems without an IOMMU, which could result in the DMA accessing
> the
> + system memory at unexpected times and/or unexpected addresses,
> + possibly leading to data leakage or corruption. The feature on its
> own
> + provides a basic level of protection against the DMA overwriting
> buffer
> + contents at unexpected times. However, to protect against general
> data
> + leakage and system memory corruption, the system needs to provide a
> + way to restrict the DMA to a predefined memory region.
I'm pretty sure we already support per device carveouts and I don't
understand how this is different.
What is the last sentence supposed to imply? You need an IOMMU?
> - vendor specific string in the form <vendor>,[<device>-]<usage>
> no-map (optional) - empty property
> - Indicates the operating system must not create a virtual mapping
> @@ -117,6 +135,16 @@ one for multimedia processing (named
> multimedia-memory@77000000, 64MiB).
> compatible = "acme,multimedia-memory";
> reg = <0x77000000 0x4000000>;
> };
> +
> + wifi_coherent_mem_region: wifi_coherent_mem_region {
> + compatible = "shared-dma-pool";
> + reg = <0x50000000 0x400000>;
> + };
> +
> + wifi_device_swiotlb_region: wifi_device_swiotlb_region {
> + compatible = "device-swiotlb-pool";
> + reg = <0x50400000 0x4000000>;
> + };
> };
>
> /* ... */
> @@ -135,4 +163,11 @@ one for multimedia processing (named
> multimedia-memory@77000000, 64MiB).
> memory-region = <&multimedia_reserved>;
> /* ... */
> };
> +
> + pcie_wifi: pcie_wifi@0,0 {
> + memory-region = <&wifi_coherent_mem_region>,
> + <&wifi_device_swiotlb_region>;
> + restricted-dma = <0>, <1>;
> + /* ... */
> + };
> };
> --
> 2.28.0.rc0.142.g3c755180ce-goog
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
