Re: [PATCH v8 15/23] dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks

On Wed, Jul 29, 2026 at 02:39:08PM +0530, Aneesh Kumar K.V wrote:

Mostafa Saleh [off-list ref] writes:

quoted

quoted

 static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size,
-		bool is_ram)
+		bool is_ram, unsigned long attrs)
 {
 	dma_addr_t end = addr + size - 1;
 
 	if (addr == DMA_MAPPING_ERROR)
 		return false;
+	/*
+	 * The DMA address was derived from encrypted RAM, but this device
+	 * requires unencrypted DMA addresses. Treat it as not DMA-capable
+	 * so the caller can fall back to a suitable SWIOTLB pool.
+	 */
+	if (!(attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
+		return false;
+

I guess it does not make sense to check the other way? I'd be worried if
some a confidential device uses shared memory which might leak info.

From the perspective of the dma_capable() check, this should be allowed;
that is, a trusted device is permitted to access shared memory.

Right, we have use cases that require confidential devices to use
shared memory we cannot block it at the DMA layer.

It would be a reasonable DMA debugging to block shared memory without
the DMA ATTR CC SHARED.

Jason