Re: [RFC PATCH 2/7] dma-direct: use DMA_ATTR_CC_DECRYPTED in alloc/free paths

[Aneesh Kumar K . V]

Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxx> writes:

> Jason Gunthorpe <jgg@xxxxxxxx> writes:
>
>> On Fri, Apr 17, 2026 at 02:28:55PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>> Propagate force_dma_unencrypted() into DMA_ATTR_CC_DECRYPTED in the
>>> dma-direct allocation path and use the attribute to drive the related
>>> decisions.
>>> 
>>> This updates dma_direct_alloc(), dma_direct_free(), and
>>> dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.
>>> 
>>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@xxxxxxxxxx>
>>> ---
>>>  kernel/dma/direct.c | 34 ++++++++++++++++++++++++++--------
>>>  1 file changed, 26 insertions(+), 8 deletions(-)
>>> 
>>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>>> index c2a43e4ef902..3932033f4d8c 100644
>>> --- a/kernel/dma/direct.c
>>> +++ b/kernel/dma/direct.c
>>> @@ -201,16 +201,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>>  		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
>>>  {
>>>  	bool remap = false, set_uncached = false;
>>> -	bool mark_mem_decrypt = true;
>>> +	bool mark_mem_decrypt = !!(attrs & DMA_ATTR_CC_DECRYPTED);
>>>  	struct page *page;
>>
>> This is changing the API, I think it should not be hidden in a patch
>> like this, also not sure it even makes sense..
>>
>> DMA_ATTR_CC_DECRYPTED only says the address passed to mapping is
>> decrypted. It is like DMA_ATTR_MMIO in this regard.
>>
>> Passing it to dma_alloc_attrs() is currently invalid, and I think it
>> should remain invalid, or at least this new behavior introduced in its
>> own patch deliberately.
>>

Thinking about this further, I am wondering why you consider passing
DMA_ATTR_CC_DECRYPTED invalid. That could be one way for a T=1 device to
request decrypted memory. We do not fully support that today, but is
there any specific reason you object to allowing DMA_ATTR_CC_DECRYPTED
in the allocation paths?

I understand that DMA_ATTR_CC_DECRYPTED is currently used to describe
already allocated memory, but extending it to also indicate a DMA
address attribute would simplify the allocation path. We could then
avoid passing a separate unencrypted/decrypted flag to the various
functions that already take an attrs argument in the allocation path.

How about making the change below so that we only prevent
dma_alloc_attrs() from accepting DMA_ATTR_CC_DECRYPTED?

modified   kernel/dma/direct.c
@@ -204,11 +204,14 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
 	bool remap = false, set_uncached = false;
-	bool mark_mem_decrypt = !!(attrs & DMA_ATTR_CC_DECRYPTED);
+	bool mark_mem_decrypt = false;
 	bool allow_highmem = true;
 	struct page *page;
 	void *ret;
 
+	if (attrs & DMA_ATTR_CC_DECRYPTED)
+		return NULL;
+
 	if (force_dma_unencrypted(dev)) {
 		attrs |= DMA_ATTR_CC_DECRYPTED;
 		mark_mem_decrypt = true;
@@ -345,7 +348,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 void dma_direct_free(struct device *dev, size_t size,
 		void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
 {
-	bool mark_mem_encrypted = !!(attrs & DMA_ATTR_CC_DECRYPTED);
+	bool mark_mem_encrypted = false;
 	unsigned int page_order = get_order(size);
 
 	/*

-aneesh