Re: [RFC PATCH v2 1/5] dma-mapping: Avoid double decrypting with DMA_RESTRICTED_POOL

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Apr 13, 2026 at 08:55:28PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
> 
> > On Mon, Apr 13, 2026 at 11:30:38AM +0530, Aneesh Kumar K.V wrote:
> >
> >> I know there is a v3, but I’m commenting here to check whether we really
> >> need to do this now. In my opinion, we can keep this much simpler by
> >> treating all swiotlb allocations as decrypted allocations. 
> >
> > That's not going to work when we get to supporting T=1 devices that
> > may still want SWIOTLB for encrypted memory.
> >
> 
> Earlier discussions indicated that a T=1 device would not require a
> bounce buffer. On ARM, we require such devices to support 64-bit DMA so
> they can operate with an unprotected IPA.

That was somewhat different. To have a sane system a T=1 device should
be able to access unprotected memory and there is no *requirement*
that bounce buffering is used.

That is very different from saying that SWIOTLB in the kernel is
completely broken and unworking on T=1 devices. We should not do that,
it should work correctly and we should have a sensible architecture
here. It is just something that would never/rarely be triggered.

Jason