From: Sumit Semwal <sumit.semwal@linaro.org>
To: sumit.semwal@linaro.org, christian.koenig@amd.com
Cc: jgg@ziepe.ca, jiri@resnulli.us, hch@infradead.org,
maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com,
chleroy@kernel.org, linuxppc-dev@lists.ozlabs.org, lkp@intel.com,
agordeev@linux.ibm.com, gerald.schaefer@linux.ibm.com,
linux-s390@vger.kernel.org, djbw@kernel.org,
thomas.lendacky@amd.com, x86@kernel.org, arnd@linaro.org,
benjamin.gaignard@collabora.com, Brian.Starkey@arm.com,
jstultz@google.com, tjmercier@google.com, mripard@kernel.org,
afd@ti.com, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>
Subject: [PATCH] dma-buf: move system_cc_shared heap under separate Kconfig
Date: Wed, 10 Jun 2026 19:53:29 +0530 [thread overview]
Message-ID: <20260610142329.3836808-1-sumit.semwal@linaro.org> (raw)
From: Arnd Bergmann <arnd@arndb.de>
While system heap and system_cc_shared heap share a lot of code
and hence the same source file, their users have different needs.
system heap users need it to be a loadable module, while
system_cc_shared heap users don't.
Building as a loadable module breaks system_cc_shared heap on
powerpc and s390 due to un-exported set_memory_encrypted /
set_memory_decrypted functions.
Fix these by reorganising code to put the system_cc_shared heap
under a new Kconfig symbol, which allows either building both
into the kernel, or leave encryption up to the consumers of the
system heap.
Fixes: fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
drivers/dma-buf/heaps/Kconfig | 8 ++++++++
drivers/dma-buf/heaps/system_heap.c | 16 ++++++++++------
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index e273fb18feca..a39decdcf067 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -5,6 +5,14 @@ config DMABUF_HEAPS_SYSTEM
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
+config DMABUF_HEAPS_CC_SYSTEM
+ bool "DMA-BUF System Heap for decrypted CoCo VMs"
+ depends on DMABUF_HEAPS && ARCH_HAS_MEM_ENCRYPT && DMABUF_HEAPS_SYSTEM=y
+ help
+ Choose this option to enable the system_cc_shared dmabuf heap. This
+ allows allocating shared (decrypted) memory for confidential computing
+ (CoCo) VMs.
+
config DMABUF_HEAPS_CMA
tristate "DMA-BUF CMA Heap"
depends on DMABUF_HEAPS && DMA_CMA
diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
index c92bdec356fc..71d9028cc3df 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -48,6 +48,9 @@ struct dma_heap_attachment {
bool cc_shared;
};
+#define cc_shared_buffer(b) (IS_ENABLED(CONFIG_DMABUF_HEAPS_CC_SYSTEM) && \
+ (b)->cc_shared)
+
#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO)
#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
| __GFP_NORETRY) & ~__GFP_RECLAIM) \
@@ -161,7 +164,7 @@ static struct sg_table *system_heap_map_dma_buf(struct dma_buf_attachment *attac
unsigned long attrs;
int ret;
- attrs = a->cc_shared ? DMA_ATTR_CC_SHARED : 0;
+ attrs = cc_shared_buffer(a) ? DMA_ATTR_CC_SHARED : 0;
ret = dma_map_sgtable(attachment->dev, table, direction, attrs);
if (ret)
return ERR_PTR(ret);
@@ -233,7 +236,7 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
int i, ret;
prot = vma->vm_page_prot;
- if (buffer->cc_shared)
+ if (cc_shared_buffer(buffer))
prot = pgprot_decrypted(prot);
for_each_sgtable_sg(table, sg, i) {
@@ -282,7 +285,7 @@ static void *system_heap_do_vmap(struct system_heap_buffer *buffer)
}
prot = PAGE_KERNEL;
- if (buffer->cc_shared)
+ if (cc_shared_buffer(buffer))
prot = pgprot_decrypted(prot);
vaddr = vmap(pages, npages, VM_MAP, prot);
vfree(pages);
@@ -349,7 +352,7 @@ static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
* Intentionally leak pages that cannot be re-encrypted
* to prevent shared memory from being reused.
*/
- if (buffer->cc_shared &&
+ if (cc_shared_buffer(buffer) &&
system_heap_set_page_encrypted(page))
continue;
@@ -456,7 +459,7 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
list_del(&page->lru);
}
- if (cc_shared) {
+ if (cc_shared_buffer(buffer)) {
for_each_sgtable_sg(table, sg, i) {
ret = system_heap_set_page_decrypted(sg_page(sg));
if (ret)
@@ -485,7 +488,7 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
* Intentionally leak pages that cannot be re-encrypted
* to prevent shared memory from being reused.
*/
- if (buffer->cc_shared &&
+ if (cc_shared_buffer(buffer) &&
system_heap_set_page_encrypted(p))
continue;
__free_pages(p, compound_order(p));
@@ -525,6 +528,7 @@ static int __init system_heap_create(void)
return PTR_ERR(sys_heap);
if (IS_ENABLED(CONFIG_HIGHMEM) ||
+ !IS_ENABLED(CONFIG_DMABUF_HEAPS_CC_SYSTEM) ||
!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
return 0;
--
2.43.0
next reply other threads:[~2026-06-10 14:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 14:23 Sumit Semwal [this message]
2026-06-10 15:23 ` [PATCH] dma-buf: move system_cc_shared heap under separate Kconfig T.J. Mercier
2026-06-11 7:35 ` Maxime Ripard
2026-06-11 10:21 ` Jiri Pirko
2026-06-11 14:45 ` Sumit Semwal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260610142329.3836808-1-sumit.semwal@linaro.org \
--to=sumit.semwal@linaro.org \
--cc=Brian.Starkey@arm.com \
--cc=afd@ti.com \
--cc=agordeev@linux.ibm.com \
--cc=arnd@arndb.de \
--cc=arnd@linaro.org \
--cc=benjamin.gaignard@collabora.com \
--cc=chleroy@kernel.org \
--cc=christian.koenig@amd.com \
--cc=djbw@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=hch@infradead.org \
--cc=jgg@ziepe.ca \
--cc=jiri@resnulli.us \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=mripard@kernel.org \
--cc=npiggin@gmail.com \
--cc=thomas.lendacky@amd.com \
--cc=tjmercier@google.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox