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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Aug 07, 2026 at 12:03:14PM +0100, Robin Murphy wrote:
> > 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.
> 
> I see we no longer seem to have the concern of devices in TDISP RUN state
> being able to send T=0 transactions other than MSI writes,

Right it was too complex and nobody needed it, so Linux will not
support T=0 through the DMA API on an T=1 device, and devices should
be designed to only send T=1 to the greatest degree possible.

If someone foolishly makes a device that works otherwise they will
have to take the difficult SW tasks of making it work.

> where GICv3 means the host is already going to have to be in on the
> game to some degree there anyway.

As I understand it:

We will need to teach GIC to understand if/when the device uses a T=0
translation for MSI and then use a shared physical address for the ITS
IOVA instead of getting an IOVA translation from the iommu. The
hypervisor will setup the S2 for the T=0 SMMU translation to be
identity with all shared memory and the ITS page will be shared
memory.

Presumably in future we will have HW to handle a T=1 ITS page access
and some way to negotiate with devices if they should use a T=1 path
for MSI or not.

There won't be a vSMMU attached to the T=0 instance at all, it is just
wired to be bypass.

> support in firmware bindings nor the IOMMU API itself to be able to describe
> a single device being associated with both the RMM's vSMMU for the T=1
> (Realm) VA space, and the NS VMM's vSMMU for the T=0 VA space, even
> if we

Right!

> did only have to care about using strictly one or the other at any given
> time based on device state. Having distinct struct devices is indeed clunky,
> but does at least reduce the problem to a currently-manageable one of the
> client driver having to wrangle them as a pair. 

So hard! A meaningful goal here is to have existing drivers largely
work unchanged in a CC world, so the device starts doing T=1 for
almost everything and the existing driver just works.

> (And FWIW when we do get there, I'd be inclined to make the default SWIOTLB
> the "private" one, so all the sharing/decryption stuff can be neatly
> partitioned off into the CoCo etc. special cases...)

Yeah
 
Jason