Re: [PATCH v2 7/8] dma-direct: set decrypted flag for remapped DMA allocations

Suzuki K Poulose
2026-04-21T12:54:56Z

On 21/04/2026 13:34, Jason Gunthorpe wrote:
> On Mon, Apr 20, 2026 at 11:44:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> Devices that are DMA non-coherent and require a remap were skipping
>> dma_set_decrypted(), leaving DMA buffers encrypted even when the device
>> requires unencrypted access. Move the call after the if (remap) branch
>> so that both the direct and remapped allocation paths correctly mark the
>> allocation as decrypted (or fail cleanly) before use.
>>
>> Architectures such as arm64 cannot mark vmap addresses as decrypted, and
>> highmem pages necessarily require a vmap remap.
>
> I don't think I saw an aswer for this, why can't arm accept
> pgprot_decrypted() for vmap? It really should, I don't think we should
> have these minor pointless arch differences.
>
> Suzuki? You mentioned it, can you elaborate?

We can accept pgprot_decrypted(), but this must be done carefully
as the backing pages must be first converted to "decrypted" in the
linear map (set_memory_decrypted()).

With that in place, it should be fine. It is,
set_memory_decrypted(vmalloc_address) is we don't support.

Cheers
Suzuki

>
> Jason