Re: [RFC PATCH v3 3/5] dma-mapping: Decrypt memory on remap

[Aneesh Kumar K . V]

Catalin Marinas <catalin.marinas@xxxxxxx> writes:

> On Tue, Apr 14, 2026 at 03:01:15PM +0530, Aneesh Kumar K.V wrote:
>> Mostafa Saleh <smostafa@xxxxxxxxxx> writes:
>> > In case memory needs to be remapped on systems with
>> > force_dma_unencrypted(), where this memory is not allocated
>> > from a restricted-dma pool, this was currently ignored, while only
>> > setting the decrypted pgprot in the remapped alias.
>> >
>> > The memory still needs to be decrypted in that case.
>> 
>> For ARM CCA, we cannot mark a vmap address as decrypted. I don’t expect
>> non-coherent DMA devices to be used in an ARM CCA configuration, but we
>> may need a way to document this in the code.
>
> I think you clarified what you meant later. The vmap here is just fine,
> we pass pgprot_decrypted(). The key is the dma_set_decrypted() on the
> page address before being remapped.
>
> On arm64 we probably don't care but if we want to enforce it for all
> architectures, dma_direct_alloc() could return NULL if
> force_dma_unencrypted() && remap (maybe together with a WARN_ON_ONCE).
> However, the proposed patch is small enough to cover this case as well.
>

I have posted a new series clarifying the commit message and adding further
changes here https://lore.kernel.org/all/20260427055509.898190-1-aneesh.kumar@xxxxxxxxxx

-aneesh