linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>, linux-kernel@vger.kernel.org
Cc: bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com,
	opendmb@gmail.com, robh@kernel.org, will@kernel.org,
	tientzu@chromium.org, Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	"open list:DMA MAPPING HELPERS"
	<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH] dma-contiguous: Prioritize restricted DMA pool over shared DMA pool
Date: Wed, 16 Feb 2022 11:13:12 +0000	[thread overview]
Message-ID: <39ed2187-2345-297d-2dd3-0b0974ce8b31@arm.com> (raw)
In-Reply-To: <20220215224344.1779145-1-f.fainelli@gmail.com>

On 2022-02-15 22:43, Florian Fainelli wrote:
> Some platforms might define the same memory region to be suitable for
> used by a kernel supporting CONFIG_DMA_RESTRICTED_POOL while maintaining
> compatibility with older kernels that do not support that. This is
> achieved by declaring the node this way;

Those platforms are doing something inexplicably wrong, then.

"restricted-dma-pool" says that DMA for the device has to be bounced 
through a dedicated pool because it can't be trusted with visibility of 
regular OS memory. "reusable" tells the OS that it's safe to use the 
pool as regular OS memory while it's idle. Do you see how those concepts 
are fundamentally incompatible?

Linux is right to reject contradictory information rather than attempt 
to guess at what might be safe or not.

Furthermore, down at the practical level, a SWIOTLB pool is used for 
bouncing streaming DMA API mappings, while a coherent/CMA pool is used 
for coherent DMA API allocations; they are not functionally 
interchangeable either. If a device depends on coherent allocations 
rather than streaming DMA, it should still have a coherent pool even 
under a physical memory protection scheme, and if it needs both 
streaming DMA and coherent buffers then it can have both types of pool - 
the bindings explicitly call that out. It's true that SWIOTLB pools can 
act as an emergency fallback for small allocations for I/O-coherent 
devices, but that's not really intended to be relied upon heavily.

So no, I do not see anything wrong with the current handling of 
nonsensical DTs here, sorry.

Robin.

> 	cma@40000000 {
> 		compatible = "restricted-dma-pool", "shared-dma-pool";
> 		reusable;
> 		...
> 	};
> 
> A newer kernel would leverage the 'restricted-dma-pool' compatible
> string for that reserved region, while an older kernel would use the
> 'shared-dma-pool' compatibility string.
> 
> Due to the link ordering between files under kernel/dma/ however,
> contiguous.c would try to claim the region and we would never get a
> chance for swiotlb.c to claim that reserved memory region.
> 
> To that extent, update kernel/dma/contiguous.c in order to check
> specifically for the 'restricted-dma-pool' compatibility string when
> CONFIG_DMA_RESTRICTED_POOL is enabled and give up that region such that
> kernel/dma/swiotlb.c has a chance to claim it.
> 
> Similarly, kernel/dma/swiotlb.c is updated to remove the check for the
> 'reusable' property because that check is not useful. When a region is
> defined with a compatible string set to 'restricted-dma-pool', no code
> under kernel/dma/{contiguous,coherent}.c will match that region since
> there is no 'shared-dma-pool' compatible string. If a
> region is defined with a compatible string set as above with both
> 'restricted-dma-pool" *and* 'shared-dma-pool' however, checking for
> 'reusable' will prevent kernel/dma/swiotlb.c from claiming the region
> while it is still perfectly suitable since contiguous.c gave it up.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
>   kernel/dma/contiguous.c | 7 +++++++
>   kernel/dma/swiotlb.c    | 3 +--
>   2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 3d63d91cba5c..3c418af6d306 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -416,6 +416,13 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
>   	    of_get_flat_dt_prop(node, "no-map", NULL))
>   		return -EINVAL;
>   
> +#ifdef CONFIG_DMA_RESTRICTED_POOL
> +	if (of_flat_dt_is_compatible(node, "restricted-dma-pool")) {
> +		pr_warn("Giving up %pa for restricted DMA pool\n", &rmem->base);
> +		return -ENOENT;
> +	}
> +#endif
> +
>   	if ((rmem->base & mask) || (rmem->size & mask)) {
>   		pr_err("Reserved memory: incorrect alignment of CMA region\n");
>   		return -EINVAL;
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index f1e7ea160b43..9d6e4ae74d04 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -883,8 +883,7 @@ static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
>   {
>   	unsigned long node = rmem->fdt_node;
>   
> -	if (of_get_flat_dt_prop(node, "reusable", NULL) ||
> -	    of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
> +	if (of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
>   	    of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
>   	    of_get_flat_dt_prop(node, "no-map", NULL))
>   		return -EINVAL;

  reply	other threads:[~2022-02-16 11:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 22:43 [PATCH] dma-contiguous: Prioritize restricted DMA pool over shared DMA pool Florian Fainelli
2022-02-16 11:13 ` Robin Murphy [this message]
2022-02-16 17:37   ` Florian Fainelli
2022-02-16 19:48     ` Robin Murphy
2022-02-16 20:39       ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39ed2187-2345-297d-2dd3-0b0974ce8b31@arm.com \
    --to=robin.murphy@arm.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=f.fainelli@gmail.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jim2101024@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=opendmb@gmail.com \
    --cc=robh@kernel.org \
    --cc=tientzu@chromium.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).