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/[email protected]/
(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
