On Thu, Jul 16, 2026 at 11:55:20AM +1000, Alexey Kardashevskiy wrote: > > > 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
