Re: [PATCH] dma-direct: swiotlb: Skip encryption toggles for swiotlb allocations

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Robin Murphy <robin.murphy@arm.com> writes:

> On 2026-01-09 2:51 am, Aneesh Kumar K.V wrote:
>> Robin Murphy <robin.murphy@arm.com> writes:
>> 
>>> On 2026-01-02 3:54 pm, Aneesh Kumar K.V (Arm) wrote:
>>>> Swiotlb backing pages are already mapped decrypted via
>>>> swiotlb_update_mem_attributes(), so dma-direct does not need to call
>>>> set_memory_decrypted() during allocation or re-encrypt the memory on
>>>> free.
>>>>
>>>> Handle swiotlb-backed buffers explicitly: obtain the DMA address and
>>>> zero the linear mapping for lowmem pages, and bypass the decrypt/encrypt
>>>> transitions when allocating/freeing from the swiotlb pool (detected via
>>>> swiotlb_find_pool()).
>>>
>>> swiotlb_update_mem_attributes() only applies to the default SWIOTLB
>>> buffer, while the dma_direct_alloc_swiotlb() path is only for private
>>> restricted pools (because the whole point is that restricted DMA devices
>>> cannot use the regular allocator/default pools). There is no redundancy
>>> here AFAICS.
>>>
>> 
>> But rmem_swiotlb_device_init() is also marking the entire pool decrypted
>> 
>> 	set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
>> 			     rmem->size >> PAGE_SHIFT);
>
> OK, so why doesn't the commit message mention that instead of saying 
> something which fails to justify the patch at all? ;)
>
> Furthermore, how much does this actually matter? The "real" restricted 
> DMA use-case is on systems where dma_set_decrypted() is a no-op anyway. 
> I know we used restricted DMA as a hack in the early days of CCA 
> prototyping, but is it intended to actually deploy that as a supported 
> and recommended mechanism now?
>
> Note also that the swiotlb_alloc path is essentially an emergency 
> fallback, which doesn't work for all situations anyway - any restricted 
> device that actually needs to make significant coherent allocations (or 
> rather, that firmware cannot assume won't want to do so) should really 
> have a proper coherent pool alongside its restricted one. The expected 
> use-case here is for something like a wifi driver that only needs to 
> allocate one or two small coherent buffers once at startup, then do 
> everything else with streaming DMA.
>


I was aiming to bring more consistency in how swiotlb buffers are
handled, specifically by treating all swiotlb memory as decrypted
buffers, which is also how the current code behaves.

If we are concluding that restricted DMA is not used in conjunction with
memory encryption, then we could, in fact, remove the
set_memory_decrypted() call from rmem_swiotlb_device_init() and
instead add failure conditions for force_dma_unencrypted(dev) in
is_swiotlb_for_alloc(). However, it’s worth noting that the initial
commit did take the memory encryption feature into account
(0b84e4f8b793eb4045fd64f6f514165a7974cd16).

Please let me know if you think this needs to be fixed.

-aneesh