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

On Fri, Aug 07, 2026 at 12:03:14PM +0100, Robin Murphy wrote:

quoted

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