On Thu, Jul 16, 2026 at 11:55:20AM +1000, Alexey Kardashevskiy wrote:

quoted

quoted

For AMD/SME, on host with memory encryption we now end up setting the C
bit for DMA_ATTR_MMIO. This is fine for RAM but not sure whether
some other MMIO bus understands this attribute. Maybe we should stick to
something like __phys_to_dma() for the !CC_SHARED && MMIO path. Or,
since this is not universally defined, just use the old dma_addr = phys
if MMIO and ignore any unlikely DMA offsets.

Considering for AMD/SME system an unencrypted dma addr is one without C
bit, will this be good?

Normally both encrypted and unencrypted DMA addresses do not have
Cbit, with the only exception of "iommu=pt" (which is not the
default afaik). And in this case, having Cbit in DMA handles only
makes sense if p2p trafic goes via the root port (== IOMMU in
passthrough mode, and I am not sure even about if the root port will
convert this Cbit to T=1 MMIO in this mode) but if it goes via some
PCI bridge - then Cbit won't mean encryption for sure. But I do not
know much about p2p (never touched). But in any case
force_dma_unencrypted() seems to make no sense here.

True p2p through a switch does not call the DMA API at all, it
directly stuffs the physical MMIO BAR address of the target into the
dma_addr_t - which won't have a C bit.

The DMA API is only involved if the p2p will transit through the root
port, so adding the C bit is correct.

AFAICT it is iommu=!pt that doesn't work at all since the AMD IOMMU
driver always does __sme_set() even for MMIO when forming the IOPTE,
which I guess is wrong for MMIO.

Jason