Mon, Mar 09, 2026 at 01:56:10PM +0100, [email protected] wrote: >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.
Do I understand that correctly that you suggest DMA_ATTR_DECRYPTED ? It's not uapi, so this is flexible for possible future renames.
