From: Catalin Marinas <catalin.marinas@arm.com>
To: Mostafa Saleh <smostafa@google.com>
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org,
maz@kernel.org, suzuki.poulose@arm.com
Subject: Re: [RFC PATCH 2/2] dma-mapping: Use the correct phys_to_dma() for DMA_RESTRICTED_POOL
Date: Tue, 10 Mar 2026 13:08:00 +0000 [thread overview]
Message-ID: <abAXsK6XE6119g09@arm.com> (raw)
In-Reply-To: <20260305170335.963568-3-smostafa@google.com>
On Thu, Mar 05, 2026 at 05:03:35PM +0000, Mostafa Saleh wrote:
> As restricted dma pools are always decrypted, in swiotlb.c it uses
> phys_to_dma_unencrypted() for address conversion.
>
> However, in DMA-direct, calls to phys_to_dma_direct() with
> force_dma_unencrypted() returning false, will fallback to
> phys_to_dma() which is inconsistent for memory allocated from
> restricted dma pools.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> kernel/dma/direct.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 27d804f0473f..1a402bb956d9 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -26,7 +26,7 @@ u64 zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
> static inline dma_addr_t phys_to_dma_direct(struct device *dev,
> phys_addr_t phys)
> {
> - if (force_dma_unencrypted(dev))
> + if (force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev))
> return phys_to_dma_unencrypted(dev, phys);
> return phys_to_dma(dev, phys);
> }
I couldn't fully get my head around the DMA API but I think all the
pools and bounce buffers are decrypted and protected guests (or realms
for Arm CCA) should always return true for force_dma_unencrypted(). If
that's the case, the above change wouldn't be necessary. I can see that
arm64 only does this for CCA and not pKVM guests.
Device assignment is another story that requires reworking those DMA
pools to support encrypted buffers.
--
Catalin
next prev parent reply other threads:[~2026-03-10 13:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 17:03 [RFC PATCH 0/2] dma-mapping: DMA_RESTRICTED_POOL and encryption Mostafa Saleh
2026-03-05 17:03 ` [RFC PATCH 1/2] dma-mapping: Avoid double decrypting with DMA_RESTRICTED_POOL Mostafa Saleh
2026-03-10 13:36 ` Catalin Marinas
2026-03-10 13:55 ` Catalin Marinas
2026-03-11 12:25 ` Mostafa Saleh
2026-03-13 7:36 ` Aneesh Kumar K.V
2026-03-05 17:03 ` [RFC PATCH 2/2] dma-mapping: Use the correct phys_to_dma() for DMA_RESTRICTED_POOL Mostafa Saleh
2026-03-10 13:08 ` Catalin Marinas [this message]
2026-03-10 13:20 ` Suzuki K Poulose
2026-03-11 12:28 ` Mostafa Saleh
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=abAXsK6XE6119g09@arm.com \
--to=catalin.marinas@arm.com \
--cc=iommu@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maz@kernel.org \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=suzuki.poulose@arm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.