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
