* RE: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
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
2026-09-11 8:32 ` Marek Szyprowski
2 siblings, 1 reply; 6+ messages in thread
From: Michael Kelley @ 2026-09-08 14:24 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), x86@kernel.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev
Cc: Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, Marek Szyprowski,
Mostafa Saleh, Alexander.Deucher@amd.com, Thomas.Lendacky@amd.com,
Vasant.Hegde@amd.com, Timo Witte
From: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Sent: Tuesday, September 8, 2026 4:33 AM
>
> 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
There seems to be something wrong with this link. Just viewing the
email thread in lore.kernel.org shows a [not found] error in the thread.
Michael
> 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(-)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
2026-09-08 14:24 ` Michael Kelley
@ 2026-09-08 14:31 ` Marek Szyprowski
0 siblings, 0 replies; 6+ messages in thread
From: Marek Szyprowski @ 2026-09-08 14:31 UTC (permalink / raw)
To: Michael Kelley, Aneesh Kumar K.V (Arm), x86@kernel.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev
Cc: Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, Mostafa Saleh,
Alexander.Deucher@amd.com, Thomas.Lendacky@amd.com,
Vasant.Hegde@amd.com, Timo Witte
On 08.09.2026 16:24, Michael Kelley wrote:
> From: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Sent: Tuesday, September 8, 2026 4:33 AM
>> 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
> There seems to be something wrong with this link. Just viewing the
> email thread in lore.kernel.org shows a [not found] error in the thread.
Indeed, this one works better:
https://lore.kernel.org/all/CANB4YXS=Nf-co3t8eMHtqrW4sn=1BDcP6o=EoTrgZm0WYMYTyw@mail.gmail.com/
I will amend it while applying, but I want give everyone some time for comments.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
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-10 4:30 ` Alexey Kardashevskiy
2026-09-10 6:55 ` Aneesh Kumar K.V
2026-09-11 8:32 ` Marek Szyprowski
2 siblings, 1 reply; 6+ messages in thread
From: Alexey Kardashevskiy @ 2026-09-10 4:30 UTC (permalink / raw)
To: iommu; +Cc: Aneesh Kumar K.V (Arm)
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
2026-09-10 4:30 ` Alexey Kardashevskiy
@ 2026-09-10 6:55 ` Aneesh Kumar K.V
0 siblings, 0 replies; 6+ messages in thread
From: Aneesh Kumar K.V @ 2026-09-10 6:55 UTC (permalink / raw)
To: Alexey Kardashevskiy, iommu
Alexey Kardashevskiy <aik@amd.com> writes:
> 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,
>
That would imply that, with host memory encryption, no device requires
unencrypted DMA. IIUC, that is not true. There are three cases:
1. Host memory encryption with an IOMMU: unencrypted DMA is not required.
2. Host memory encryption without an IOMMU, where the device's DMA addressing constraints cannot cover the C-bit: unencrypted DMA is required.
3. Host memory encryption without an IOMMU, where the device can address the C-bit: unencrypted DMA is not required.
-aneesh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
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-10 4:30 ` Alexey Kardashevskiy
@ 2026-09-11 8:32 ` Marek Szyprowski
2 siblings, 0 replies; 6+ messages in thread
From: Marek Szyprowski @ 2026-09-11 8:32 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), x86, linux-kernel, iommu
Cc: Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, Mostafa Saleh,
Alexander.Deucher, Thomas.Lendacky, Vasant.Hegde, Timo Witte
On 08.09.2026 13: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>
Applied to dma-mapping-fixes with adjusted url and changed 'link' tag to
the 'closes' one, thanks!
> ---
> 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);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply [flat|nested] 6+ messages in thread