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: > > 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
