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

[Tom Lendacky <thomas.lendacky@amd.com>]

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