On Thu, 5 Mar 2026 13:36:40 +0100 Jiri Pirko <[email protected]> wrote:
> From: Jiri Pirko <[email protected]> > > Current CC designs don't place a vIOMMU in front of untrusted devices. > Instead, the DMA API forces all untrusted device DMA through swiotlb > bounce buffers (is_swiotlb_force_bounce()) which copies data into > decrypted memory on behalf of the device. > > When a caller has already arranged for the memory to be decrypted > via set_memory_decrypted(), the DMA API needs to know so it can map > directly using the unencrypted physical address rather than bounce > buffering. Following the pattern of DMA_ATTR_MMIO, add > DMA_ATTR_CC_DECRYPTED for this purpose. Like the MMIO case, only the > caller knows what kind of memory it has and must inform the DMA API > for it to work correctly. > > Signed-off-by: Jiri Pirko <[email protected]> > --- > v1->v2: > - rebased on top of recent dma-mapping-fixes > --- > include/linux/dma-mapping.h | 6 ++++++ > include/trace/events/dma.h | 3 ++- > kernel/dma/direct.h | 14 +++++++++++--- > 3 files changed, 19 insertions(+), 4 deletions(-) > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h > index 29973baa0581..ae3d85e494ec 100644 > --- a/include/linux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -85,6 +85,12 @@ > * a cacheline must have this attribute for this to be considered safe. > */ > #define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11) > +/* > + * DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted > + * (shared) for confidential computing guests. The caller must have > + * called set_memory_decrypted(). A struct page is required. > + */ > +#define DMA_ATTR_CC_DECRYPTED (1UL << 12) I don't want to start a bikeshedding discussion, so if everyone else likes this name, let's keep it. But maybe the "_CC" (meaning Confidential Comptuing) is not necessary. IIUC it's the same concept as set_page_encrypted(), set_page_decrypted(), which does not refer to CoCo either. Just my two cents Petr T
