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

Alexey Kardashevskiy
2026-03-04T06:46:04Z

On 3/3/26 23:43, Jason Gunthorpe wrote:
> On Mon, Mar 02, 2026 at 08:19:11PM -0400, Jason Gunthorpe wrote:
>>> Oh, I thought SEV-TIO had trouble with this, if this is indeed the case,
>>> great, ignore my first comment.
>>
>> Alexey?
>>
>> I think it is really important that shared mappings continue to be
>> reachable by TDISP device.
>
> I think Alexey has clarified this in the other thread, and probably
> AMD has some work to do here.
>
> The issue is AMD does not have seperate address spaces for
> shared/private like ARM does, instead it relies on a C bit in the *PTE*
> to determine shared/private.
>
> The S2 IOMMU page table *does* have the full mapping of all shared &
> private pages but the HW requires a matching C bit to permit access.
>
> If there is a S1 IOMMU then the IOPTEs of the VM can provide the C
> bit, so no problem.
>
> If there is no S1 then the sDTE of the hypervisor controls the C bit,

sDTE is controlled by the FW (not the HV) on the VM behalf - the VM chooses whether to enable sDTE and therefore vTOM.

> and it sounds like currently AMD sets this globally which effectively
> locks TDISP RUN devices to *only* access private memory.

Right. The assumption is that if the guest wants finer control - there is secure vIOMMU (in the works).

> I suspect AMD needs to use their vTOM feature to allow shared memory
> to remain available to TDISP RUN with a high/low address split.
I could probably do something about it bit I wonder what is the real live use case which requires leaking SME mask, have a live example which I could try recreating?

> Alexey, did I capture this properly?

Yes, with the correction about sDTE above. Thanks,

>
> Jason

--
Alexey