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

[Jason Gunthorpe]

On Tue, Apr 14, 2026 at 06:43:49PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@xxxxxxxx> 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.
> >
> > Why not? pgprot_decrypted is passed to vmap, why can't it work?
> >
> 
> 
> I might have confused you in my previous reply. What I meant is that, if
> we do not have a linear map, we currently cannot change the page
> attributes. 

I'm not sure that is really a CCA issue..

We have an API design problem with set_memory_decrypted(), it needs
three flavours to accommodate all the different users

 kva void *
 cpu memory struct page *
 physical mmio phys_addr_t

Currently these are all being muddled up with quite some creative
mis-use of APIs. The DMA API should just call the page * version and
not invoke page address.

I guess this became extra complex because Intel needs to track down
the KVAs and wipe them out.

> What I am suggesting here is that we should document this, or perhaps
> handle it as a separate patch as done in [1] by explicitly stating the
> challenges

It should be centralized.. If we had a struct page argument version it
could do the page highmem check and fail with an appropriate comment.

This shouldn't be sprinkled all over.

I suspect it could all be made to work even with highmem without alot
of trouble.

Jason