[PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices

[PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices

[Aneesh Kumar K.V (Arm)]

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);
-- 
2.43.0

RE: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices

[Michael Kelley]

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(-)

Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices

[Marek Szyprowski]

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

Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices

[Marek Szyprowski]

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

Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices

[Tom Lendacky]

On 9/8/26 06: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)) {

When this support was originally added many years ago, this function was
not called if an IOMMU was active and generating IOVAs. So if this
function is now called even when an IOMMU is performing the DMA mapping,
then this is appropriate. Although, it would seem that if an IOMMU is
performing the mapping and this function is still being called, checking
use_dma_iommu(dev) and exiting early from force_dma_unencrypted() at the
very beginning is more appropriate, right?

@Alexey, would that impact your TIO/TDISP support at all?

Thanks,
Tom

>  		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);

Re: [PATCH] x86/mm: Don't force unencrypted DMA for IOMMU-backed devices

[Aneesh Kumar K.V]

Tom Lendacky <thomas.lendacky@amd.com> writes:

> On 9/8/26 06:32, Aneesh Kumar K.V (Arm) wrote:

 [ ... 39 lines skipped ... ] 

>>  
>> @@ -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)) {
>
> When this support was originally added many years ago, this function was
> not called if an IOMMU was active and generating IOVAs. So if this
> function is now called even when an IOMMU is performing the DMA mapping,
> then this is appropriate. Although, it would seem that if an IOMMU is
> performing the mapping and this function is still being called, checking
> use_dma_iommu(dev) and exiting early from force_dma_unencrypted() at the
> very beginning is more appropriate, right?
>

I don't think that is correct for a confidential guest with a stage-1 IOMMU.


> @Alexey, would that impact your TIO/TDISP support at all?
>

-aneesh