| 78b30c50 | 25-Mar-2026 |
Jiri Pirko <jiri@nvidia.com> |
dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory
Add a new "system_cc_shared" dma-buf heap to allow userspace to
allocate shared (decrypted) memory for confidential com
dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory
Add a new "system_cc_shared" dma-buf heap to allow userspace to
allocate shared (decrypted) memory for confidential computing (CoCo)
VMs.
On CoCo VMs, guest memory is private by default. The hardware uses an
encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on
Intel TDX) to control whether a given memory access is private or
shared. The kernel's direct map is set up as private,
so pages returned by alloc_pages() are private in the direct map
by default. To make this memory usable for devices that do not support
DMA to private memory (no TDISP support), it has to be explicitly
shared. A couple of things are needed to properly handle
shared memory for the dma-buf use case:
- set_memory_decrypted() on the direct map after allocation:
Besides clearing the encryption bit in the direct map PTEs, this
also notifies the hypervisor about the page state change. On free,
the inverse set_memory_encrypted() must be called before returning
pages to the allocator. If re-encryption fails, pages
are intentionally leaked to prevent shared memory from being
reused as private.
- pgprot_decrypted() for userspace and kernel virtual mappings:
Any new mapping of the shared pages, be it to userspace via
mmap or to kernel vmalloc space via vmap, creates PTEs independent
of the direct map. These must also have the encryption bit cleared,
otherwise accesses through them would see encrypted (garbage) data.
- DMA_ATTR_CC_SHARED for DMA mapping:
Since the pages are already shared, the DMA API needs to be
informed via DMA_ATTR_CC_SHARED so it can map them correctly
as unencrypted for device access.
On non-CoCo VMs, the system_cc_shared heap is not registered
to prevent misuse by userspace that does not understand
the security implications of explicitly shared memory.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20260325192352.437608-3-jiri@resnulli.us
show more ...
|
| 252b0e79 | 10-Mar-2026 |
Linus Walleij <linusw@kernel.org> |
dma-buf: heaps: Clear CMA highages using helper
Currently the CMA allocator clears highmem pages using
kmap()->clear_page()->kunmap(), but there is a helper
static inline in <linux/highmem.h> that d
dma-buf: heaps: Clear CMA highages using helper
Currently the CMA allocator clears highmem pages using
kmap()->clear_page()->kunmap(), but there is a helper
static inline in <linux/highmem.h> that does the same for
us so use clear_highpage() instead of open coding this.
Suggested-by: T.J. Mercier <tjmercier@google.com>
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260310-cma-heap-clear-pages-v2-2-ecbbed3d7e6d@kernel.org
show more ...
|
| 4f5f8baf | 13-Oct-2025 |
Maxime Ripard <mripard@kernel.org> |
dma-buf: heaps: cma: Create CMA heap for each CMA reserved region
Aside from the main CMA region, it can be useful to allow userspace to
allocate from the other CMA reserved regions.
Indeed, those
dma-buf: heaps: cma: Create CMA heap for each CMA reserved region
Aside from the main CMA region, it can be useful to allow userspace to
allocate from the other CMA reserved regions.
Indeed, those regions can have specific properties that can be useful to
a specific us-case.
For example, one of them platform I've been with has ECC enabled on the
entire memory but for a specific region. Using that region to allocate
framebuffers can be particular beneficial because enabling the ECC has a
performance and memory footprint cost.
Thus, exposing these regions as heaps user-space can allocate from and
import wherever needed allows to cover that use-case.
For now, only shared-dma-pools regions with the reusable property (ie,
backed by CMA) are supported, but eventually we'll want to support other
DMA pools types.
Since we collected all the CMA regions created during boot, we can
simply iterate over all of them to create the heaps.
This has a weird interaction with the recent work on the CMA name, in
particular the backward compatibility code created by commit
854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name").
Indeed, the old name was either 'reserved', or the name of the
reserved-memory region device tree node if the linux,cma-default
property was set.
In both these cases, we have now collected this region during boot, and
we're using the same name. So we're now largely redundant with the
code to handle backward compatibility code, and we can thus remove it
and the associated Kconfig option.
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: rebased the doc to latest]
Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-5-04ce150ea3d9@kernel.org
show more ...
|
| 854acbe7 | 10-Jun-2025 |
Jared Kangas <jkangas@redhat.com> |
dma-buf: heaps: Give default CMA heap a fixed name
The CMA heap's name in devtmpfs can vary depending on how the heap is
defined. Its name defaults to "reserved", but if a CMA area is defined
in the
dma-buf: heaps: Give default CMA heap a fixed name
The CMA heap's name in devtmpfs can vary depending on how the heap is
defined. Its name defaults to "reserved", but if a CMA area is defined
in the devicetree, the heap takes on the devicetree node's name, such as
"default-pool" or "linux,cma". To simplify naming, unconditionally name
it "default_cma_region", but keep a legacy node in place backed by the
same underlying allocator for backwards compatibility.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20250610131231.1724627-4-jkangas@redhat.com
show more ...
|
| 86e59cc5 | 10-Jun-2025 |
Jared Kangas <jkangas@redhat.com> |
dma-buf: heaps: Parameterize heap name in __add_cma_heap()
Prepare for the introduction of a fixed-name CMA heap by replacing the
unused void pointer parameter in __add_cma_heap() with the heap name
dma-buf: heaps: Parameterize heap name in __add_cma_heap()
Prepare for the introduction of a fixed-name CMA heap by replacing the
unused void pointer parameter in __add_cma_heap() with the heap name.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Acked-by: John Stultz <jstultz@google.com>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20250610131231.1724627-3-jkangas@redhat.com
show more ...
|