From: Alexey Kardashevskiy <aik@amd.com>
To: iommu@lists.linux.dev
Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Subject: Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
Date: Thu, 10 Sep 2026 14:30:07 +1000 [thread overview]
Message-ID: <da147aa4-79b6-4388-bdf4-d1af28b1ae77@amd.com> (raw)
In-Reply-To: <20260908113232.247457-1-aneesh.kumar@kernel.org>
On 8/9/26 21:32, Aneesh Kumar K.V (Arm) wrote:
> Commit 8277a12d0d60 ("dma-pool: track decrypted atomic pools and select
> them via attrs") exposed an issue with force_dma_unencrypted() on
> systems using host memory encryption.
>
> force_dma_unencrypted() checks whether the device DMA mask can address
> the encryption bit and, if not, requires DMA allocations to use
> unencrypted memory. However, this check is not applicable when the
> device is using the IOMMU. In that case, the device DMA mask constrains
> the IOVA seen by the device, not the backing physical address, so it
> does not need to cover the C-bit.
>
> This currently causes dma_alloc_attrs() to set
> __DMA_ATTR_ALLOC_CC_SHARED for such devices. iommu_dma_alloc() does not
> support that attribute and rejects the allocation, causing DMA
> allocations to fail.
>
> Do not force DMA allocations to be unencrypted when the device is using
> the IOMMU. This allows the IOMMU to map the encrypted physical pages as
> before and avoids incorrectly requesting CC_SHARED allocations.
>
> Fixes: 8277a12d0d60 ("dma-pool: track decrypted atomic pools and select them via attrs")
> Reported-by: Timo Witte <timo.witte@gmail.com>
> Link: https://lore.kernel.org/all/CANB4YXR7h8V5Xp=MXVZeSdvw9UiriSagp=E+ju5RRDNghoPHLQ@mail.gmail.com
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/x86/mm/mem_encrypt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 912f22ca838f..a349d8d21569 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -13,6 +13,7 @@
> #include <linux/cc_platform.h>
> #include <linux/mem_encrypt.h>
> #include <linux/virtio_anchor.h>
> +#include <linux/iommu-dma.h>
>
> #include <asm/sev.h>
>
> @@ -30,7 +31,7 @@ bool force_dma_unencrypted(struct device *dev)
> * device does not support DMA to addresses that include the
> * encryption mask.
> */
> - if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
> + if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) && !use_dma_iommu(dev)) {
> u64 dma_enc_mask = DMA_BIT_MASK(__ffs64(sme_me_mask));
> u64 dma_dev_mask = min_not_zero(dev->coherent_dma_mask,
> dev->bus_dma_limit);
if we drop this whole "if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))" chunk, won't dma_alloc_attrs()&co be able to figure out this from dev->bus_dma_limit and other DMA masks we have all over the place? I should probably just try it... Thanks,
--
Alexey
next prev parent reply other threads:[~2026-09-10 4:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260908113247eucas1p12e67fcdf50573da0c0fac36cee4b06e9@eucas1p1.samsung.com>
2026-09-08 11:32 ` [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices Aneesh Kumar K.V (Arm)
2026-09-08 14:24 ` Michael Kelley
2026-09-08 14:31 ` Marek Szyprowski
2026-09-10 4:30 ` Alexey Kardashevskiy [this message]
2026-09-10 6:55 ` Aneesh Kumar K.V
2026-09-11 8:32 ` Marek Szyprowski
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=da147aa4-79b6-4388-bdf4-d1af28b1ae77@amd.com \
--to=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=iommu@lists.linux.dev \
/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.