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

[Robin Murphy]

On 07/08/2026 12:55 pm, Jason Gunthorpe wrote:
> 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.

IIRC, for MSI or unlocked MSI-X it should look and work pretty much 
exactly like regular VFIO, as everything can be mediated by the VMM and 
host kernel.

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

Locked MSI-X would be a pain right now as we cannot intercept the Realm 
programming the MSI-X cap with a doorbell address and EventID value 
decided by the ITS driver in the Realm guest, so we'd somehow have to 
sniff those values out of the VMM's vITS emulation then try to configure 
an equivalent NS LPI to match, or have a hook in the ITS driver that 
knows when it's in a Realm and do some RSI handshake to proxy-allocate 
NS MSI vectors on the host and pass the real values back into the Realm.

I'm still hoping we (both CCA and possibly Linux in general) can get 
away with just refusing to support Locked MSI-X without GICv5, as once 
we have proper Realm MSIs with direct injection then all the problems go 
away (or at least become much smaller RMM problems that remain invisible 
to the host - the one "big" problem being that the RMM has to 
begrudgingly implement an entire GIC driver since it now has its own 
whole GIC to look after).

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

If that's all anyone will ever want then it does allow some degree of 
hackery like mirroring the whole of Realm S2 in an equivalent NS IOMMUFD 
domain, then forcing IOMMU_DOMAIN_IDENTITY for unaccepted devices within 
the guest. However I was under the impression that folks want to make 
meaningful use of devices while still in their untrusted pre-acceptance 
state (but maybe still switch them later), so it seems almost inevitable 
that eventually someone says "actually, we would like S1 vSMMU for 
untrusted scatter-gather as well..."

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

Agreed, and I think with this series we should be pretty close now, at 
least for coherent devices with 64-bit DMA masks. And from the thread 
over at [1], it sounds like Hyper-V's VMbus is ready to go as 
potentially our first user independent of any other PCI/TSM dependencies.

Cheers,
Robin.

[1] https://lore.kernel.org/all/20260803033520.12930-1-tiala@microsoft.com/

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