Re: [PATCH kernel 6/9] x86/dma-direct: Stop changing encrypted page state for TDISP devices

Alexey Kardashevskiy
2026-02-26T06:22:47Z

On 26/2/26 08:35, dan.j.williams@intel.com wrote:
> Robin Murphy wrote:
>> On 2026-02-25 5:37 am, Alexey Kardashevskiy wrote:
>>> TDISP devices operate in CoCo VMs only and capable of accessing
>>> encrypted guest memory.
>>>
>>> Currently when SME is on, the DMA subsystem forces the SME mask in
>>> DMA handles in phys_to_dma() which assumes IOMMU pass through
>>> which is never the case with CoCoVM running with a TDISP device.
>>>
>>> Define X86's version of phys_to_dma() to skip leaking SME mask to
>>> the device.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
>>> ---
>>>
>>> Doing this in the generic version breaks ARM which uses
>>> the SME mask in DMA handles, hence ARCH_HAS_PHYS_TO_DMA.
>>
>> That smells a bit off... In CCA we should be in the same boat, wherein a
>> trusted device can access memory at a DMA address based on its "normal"
>> (private) GPA, rather than having to be redirected to the shared alias
>> (it's really not an "SME mask" in that sense at all).
>
> Not quite, no, CCA *is* in the same boat as TDX, not SEV-SNP. Only
> SEV-SNP has this concept that the DMA handle for private memory is the
> dma_addr_unencrypted() conversion (C-bit masked) of the CPU physical
> address. For CCA and TDX the typical expectation of dma_addr_encrypted()
> for accepted devices holds. It just so happens that dma_addr_encrypted()
> does not munge the address on is a nop conversion for CCA and TDX.

OTOH TDX and SNP do not leak SME mask to DMA handles, and ARM does.

Sounds like what, we need sme_dma_me_mask in addition to sme_me_mask? Scary.

--
Alexey