RE: [PATCH v2 4/4] coco/tdx-host: Initialize trusted DMA on all capable IOMMUs

[Tian, Kevin]

> From: Jason Gunthorpe <jgg@xxxxxxxx>
> Sent: Friday, October 16, 2026 10:59 PM
> 
> On Fri, Oct 16, 2026 at 07:17:31AM +0000, Tian, Kevin wrote:
> > +Aneesh.
> >
> > > From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> > > Sent: Friday, October 16, 2026 3:03 PM
> > >
> > > On 10/16/2026 1:37 AM, Jason Gunthorpe wrote:
> > > > On Thu, Oct 15, 2026 at 04:31:31PM +0800, Xu Yilun wrote:
> > > >
> > > >> An alternative could be, bringing up one IOMMU when an associated
> > > >> device requests link encryption. Then a no-tdx-support iommu fails the
> > > >> encryption request naturally.
> > > > That is what ARM is planning to do. I think it is reasonable to
> > > > trigger creation of the secure iommu when the TSM is connected to TDX.
> > > >
> > > > Fail connect if the iommu could not be created.
> > >
> > > Yes, agreed. The Intel iommu driver could use per-device interfaces,
> > > just as ARM is planning. There are some differences, though.
> > >
> > > ARM's interaction with the iommu driver in viommu_init() appears to
> > > consist of two steps:
> > >
> > >   - arm_smmu_get_realm_params(dev, &params): get and validate the
> > >     physical iommu information from the arm-smmu-v3 driver;
> > >   - cca_psmmu_get(&params): activate the physical smmu for Realm use.
> > >
> > > Intel differs in two ways:
> > >
> > >   - ARM queries the physical iommu information from the iommu driver
> > >     in the viommu_init() path. On Intel, the secure iommu must be set
> > >     up during TSM connect, because it is part of establishing PCIe
> > >     link encryption.
> >
> > My understanding is that the psmmu is required for link encryption, so
> > it's similar ordering here i.e. activated before tsm connect?
> 
> No, AFAIK? The psmmu has to be linked before creating the vdev, and in
> the current spec the only way to get the measurements is through the
> vdev, but I am expecting that to change.

Okay seems I misread psmmu as pdev. It's the latter created for setting
up IDE link. As you said psmmu is only for creating the vdev.

> 
> I have no idea what brilliant idea caused the VT-d iommu HW to become
> involved in DOE and link IDE configuration in the root port. That
> makes very little sense from an architecture perspective.

Agree. 

> 
> > >   - The TDX Connect architecture places requirements on the host
> > >     iommu driver while the secure IOMMU is being set up. For example,
> > >     the host iommu driver must block the enhanced command (ECMD)
> > >     interface while the TDH.IOMMU.SETUP SEAMCALL runs, and it must
> > >     reserve the upper half of the domain ID space. These steps have
> > >     to happen atomically under the iommu driver's own locks. As a
> > >     result, the Intel iommu driver needs to merge the two steps above
> > >     into one.
> >
> > Didn't get this. Both ECMD and DID reservation are TDX specific things.
> > How are they related to the two steps in the ARM sides and why calls
> > for merging?
> >
> > and why are they must be done atomically? they are conditions to
> > execute TDH.IOMMU.SETUP, but it is perfectly fine to reserve DID
> > at an early point then block ECMD later...
> 
> That's going to be a bit of a PITA, since the DIDs can be in use when
> the tdx module is start potentially.
> 
> I suppose you can start out by just failing if this has happened.

This is the plan

> 
> But as soon as reasonably possible once the system opts into a TDX
> operation the VT-d drivers should stop using the upper did space.
> 
> Otherwise you will have to implement live DID renaming, which is a
> PITA in an iommu driver.
> 

yeah nobody wants to do that way.