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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Apr 21, 2026 at 01:54:52PM +0100, Suzuki K Poulose wrote:
> 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()).

Isn't that the case for any use of pgprot_decrypted? I think that is
fine and followed by the dma api.

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

That makes more sense. Nothing should do that, changing the state of
memory that is mapped any place other than the linear map is not
allowed. I understand this is the condition where Intel will machine
check..

So with that clarification at least the commit message should be
revised in this patch to not mention vmap.

Jason