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

[Suzuki K Poulose]

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