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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Aug 05, 2026 at 09:10:16AM +0000, Mostafa Saleh wrote:
> 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.

That seems like something very differnt.

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

We don't have any API for a DMA API caller to signal 'must be
confidential'. If we want to add one it would be a flag to check
before changing the physical address in swiotlb.

As defined today the DMA API expressly copies from private to shared
memory, that is baked into it's design and not a bug.

My expectation is all these cases have to be solved by setting up the
swiotlb properly so it provides suitable bounce buffers. Yes, this
means we will eventually need both private and shared swiotlb pools.

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

No way! That's would be a giant disaster for the driver model.

Each struct device will have a flag that shows if it is in T=1 or T=0
state. The flag can only change while a driver is not bound, and
changing the flag will update the DMA API configuration.

A T=1 device should have the same issue as you point out for pkvm, it
really needs to have a private SWIOTLB pool.
 
> 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.

It is exactly the right place because it is the one supplying the new
memory. Context is irrelevant, the flag only describes what the new
memory actually *IS*, and swiotlb knows 100% if the new memory is
shared or private.

For your issue it would be appropriate to add a debugging check that
the new memory is not incompatible with the expected policy. eg a T=1
device getting decrypted swiotlb memory is a bug in swiotlb setup that
should be caught. But that's a debugging check, we expect the swiotlb
to have selected the right kind of memory by construction. This isn't
done yet since this series doesn't even yet support a T=1 device..

Jason