Re: [PATCH v8 12/23] dma: swiotlb: pass mapping attributes by reference

On Tue, Aug 04, 2026 at 11:20:32AM -0300, Jason Gunthorpe wrote:

On Wed, Jul 29, 2026 at 06:12:38PM +0530, Aneesh Kumar K.V wrote:

quoted

There is a possibility that we may support io_tlb_mem with cc_shared =
false in the future. As a result, only swiotlb_map() knows which type of
bounce buffer was used, making it the only place where the attributes
can be updated correctly.

Yeah, +1, the attribute should be changed at the same effective place
the source memory is changed away from what the DMA API user
provided. Only the thing providing the new memory (eg swiotlb) should
know its properties.

I will keep the conversation here instead of 2 threads.

That seems like a big leap, I'd be worried about devices that operate
on confidential data that should not be shared/decrypted.

One example for this which exists in pKVM (this part is not
upstream yet) is non coherent devices that require bouncing but they
still want to keep the data private. In that case ideally they get
an encrypted SWIOTLB pool, but it's always better to fail than to use
a decrypted pool behind it's back.

I have not been following the work on T=1/T=0 devices, but IIRC, they
required some complexity to handle their stage-2 as these modes will
be emulated differently (for CCA, RMM vs untrusted host).
I was thinking that it might be easier to represent those to the
guest kernel as 2 separate devices (bounded to different groups...)
where one is trusted and the other is not, and that way the DMA-API
can have strict rules about memory sharing.

Otherwise, SWIOTLB does not seem like the right place to me, as it
does not understand the context the device is operating in, and the
DMA-API should deduce that from the flags passed.

Thanks,
Mostafa

Jason