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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Apr 15, 2026 at 06:13:17PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
> 
> > 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.
> >
> 
> For things like
> 
> #define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, 0)
> 
> Where do you suggest DMA_ATTR_CC_DECRYPTED be set?

dma_map_single() assumes that a is encrypted.

If the caller passes an a that it decrypted then it must pass
DMA_ATTR_CC_DECRYPTED.

It is NOT directly derived from force_dma_unencrypted().

If attr says encrypted and force_dma_unencrypted(), then we have to do
swiotlb, we get a new address and we track the decrypted state of the
new address along with it.

Lower levels always receive an address and a 'is decrypted' flag to
make their decisions.

The place we check force_dma_unencrypted() is while branching to
swiotlb.

swiotlb might re-use DMA_ATTR_CC_DECRYPTED, or it might use the
dma_page idea, but logically the address and a matching flag flow
together through the call chains.

Jason