Re: [PATCH kernel 4/9] dma/swiotlb: Stop forcing SWIOTLB for TDISP devices

[dan.j.williams]

Jason Gunthorpe wrote:
> On Wed, Feb 25, 2026 at 12:57:01PM -0800, dan.j.williams@xxxxxxxxx wrote:
> > > (since a device that's trusted to access private memory
> > > isn't necessarily prohibited from still also accessing shared memory as
> > > well), hmmm...
> > 
> > The specification allows it, but Linux DMA mapping core is not yet ready
> > for it. So the expectation to start is that the device loses access to
> > its original shared IOMMU mappings when converted to private operation.
> 
> Yes, the underlying translation changes, but no, it doesn't loose DMA
> access to any shared pages, it just goes through the T=1 IOMMU now.

Yes, what I meant to say is that Linux may need to be prepared for
implementations that do not copy over the shared mappings. At least for
early staging / minimum viable implementation for first merge.

> The T=1 IOMMU will still have them mapped on all three platforms
> AFAIK.

Oh, I thought SEV-TIO had trouble with this, if this is indeed the case,
great, ignore my first comment.

> On TDX/CCA the CPU and IOMMU S2 tables are identical, so of
> course the shared pages are mapped. On AMD there is only one IOMMU so
> the page must also be mapped or non-TDISP is broken.
> 
> When this TDISP awareness is put in the DMA API it needs to be done in
> a way that allows DMA_ATTR_CC_DECRYPTED to keep working for TDISP
> devices.
> 
> This is important because we are expecting these sorts of things to
> work as part of integrating non-TDISP RDMA devices into CC guests. We
> can't loose access to the shared pages that are shared with the
> non-TDISP devices...

Ok, I need to go look at this DMA_ATTR_CC_DECRYPTED proposal...

I have a v2 of a TEE I/O set going out shortly and sounds like it will
need a rethink for this attribute proposal for v3. I think it still helps to
have combo sets at this stage so the whole lifecycle is visible in one
set, but it is nearly at the point of being too big a set to consider in
one sitting.

> > So on ARM where shared addresses are high, it is future work to figure
> > out how an accepted device might also access shared mappings outside the
> > device's dma_mask.
> 
> ARM has a "solution" right now. The location of the high bit is
> controlled by the VMM and the VMM cannot create a CC VM where the IPA
> space exceeds the dma_mask of any assigned device.
> 
> Thus the VMM must limit the total available DRAM to fit within the HW
> restrictions.
> 
> Hopefully TDX can do the same.

TDX does not have the same problem, but the ARM "solution" seems
reasonable for now.