Re: [RFC PATCH v3 0/5] dma-mapping: Fixes for memory encryption

[Mostafa Saleh <smostafa@google.com>]

On Fri, Apr 10, 2026 at 02:43:38PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 08, 2026 at 07:47:37PM +0000, Mostafa Saleh wrote:
> > Introduction
> > ============
> > This is the third version of the fixes for direct-dma dealing with
> > memory encryption and restricted-dma.
> > 
> > Changes in v3:
> > - Instead of extending the logic by using is_swiotlb_for_alloc(),
> >   follow Jason’s suggestion and propagate the state of the memory
> >   allocated.
> > - Remove checks out of dma_set_*() based on Jason suggestion
> > - Remove documentation for now until we are close to the final
> >   proposal and add it later if needed.
> 
> There are a number of Sashiko remarks that look plausible that should
> be investigated:
> https://sashiko.dev/#/patchset/20260408194750.2280873-1-smostafa%40google.com

I think the remap and NULL points are valid, I will address them.

The case of dma_coherent_ok() is more tricky, it is not a regression,
but I think it’s still a theoretical problem for some CCA solutions
where encrypted/decrypted memory have different DMA aliases. It’s not
easy to fix it without having some helper to check the memory state as
force_dma_unencrypted and swiotlb_is_decrypted() which kind of defeat
the purpose of returning the memory state from swiotlb_alloc() ://

> 
> > Design
> > ======
> > This series focuses mainly on dma-direct interaction with memory
> > encryption which is the complicated case.
> > At the moment memory encryption and dma-direct interacts in 2 ways:
> > 1) force_dma_direct(): if true, memory will be decrypted by default
> >    on allocation.
> > 2) Restricted DMA: where memory is pre-decrypted and managed by
> >    SWIOTLB.
> > 
> > With a third possible usage on the way [1] where the DMA-API allows
> > an attr for decrypted memory.
> 
> This [1] was merged now

I see, I will rebase on top of it and send v4.

Thanks,
Mostafa

> 
> Jason