Re: [RFC PATCH v3 5/5] dma-mapping: Fix memory decryption issues

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Apr 13, 2026 at 12:49:34PM +0530, Aneesh Kumar K.V wrote:
> > 2) Using phys_to_dma_unencrypted() is not enlighted about already
> > decrypted memory and will use the wrong functions for that.
> 
> Can you split this into a separate patch? I’m finding it difficult to
> understand what the issue is here. Adding the unencrypted flag multiple
> times to an address is not a problem in itself. Even so, I still do not
> follow when we would end up doing that.

I think my comments show how to address it right..

> phys_to_dma_direct should depend on the device state.

No, it depends on what state the CPU address is, which in some flows
would have depended on the device state, but by the time you get to
generating a dma_addr_t it should be based 100% on the current state
of the phys_addr and nothing else.

Assuming that a T=0 device must be presented unencrypted memory is an
easy hack but it doesn't work when we get to T=1 devices that can
handle both encryped and decrypted memory. Then we need to track it
explicitly.

The only places we we should check the device state for T=0 is at the
very top when we decide if we force it to swiotlb and inside swiotlb
when we decide if the allocation should be decrypted. Everything else
should flow from tracking the phy's state, and be tied into the new
DMA ATTR UNENCRYPTED.

Jason