[PATCH v2] dma-buf: heaps: system: document system_cc_shared heap

[PATCH v2] dma-buf: heaps: system: document system_cc_shared heap

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

Document the system_cc_shared dma-buf heap that was introduced
recently. Describe its purpose, availability conditions and
relation to confidential computing VMs.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: T.J.Mercier <tjmercier@google.com>
---
 Documentation/userspace-api/dma-buf-heaps.rst | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst
index 05445c83b79a..f56b743cdb36 100644
--- a/Documentation/userspace-api/dma-buf-heaps.rst
+++ b/Documentation/userspace-api/dma-buf-heaps.rst
@@ -16,6 +16,13 @@ following heaps:
 
  - The ``system`` heap allocates virtually contiguous, cacheable, buffers.
 
+ - The ``system_cc_shared`` heap allocates virtually contiguous, cacheable,
+   buffers using shared (decrypted) memory. It is only present on
+   confidential computing (CoCo) VMs where memory encryption is active
+   (e.g., AMD SEV, Intel TDX). The allocated pages have the encryption
+   bit cleared, making them accessible for device DMA without TDISP
+   support. On non-CoCo VM configurations, this heap is not registered.
+
  - The ``default_cma_region`` heap allocates physically contiguous,
    cacheable, buffers. Only present if a CMA region is present. Such a
    region is usually created either through the kernel commandline
-- 
2.51.1

Re: [PATCH v2] dma-buf: heaps: system: document system_cc_shared heap

[Sumit Semwal]

Hello Jiri,

On Tue, 7 Apr 2026 at 14:56, Jiri Pirko <jiri@resnulli.us> wrote:
>
> From: Jiri Pirko <jiri@nvidia.com>
>
> Document the system_cc_shared dma-buf heap that was introduced
> recently. Describe its purpose, availability conditions and
> relation to confidential computing VMs.
>
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> Reviewed-by: T.J.Mercier <tjmercier@google.com>

Thank you for the patch!

Marek: Since you're taking the dependent patches through your tree,
could you please use:
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>

and take this as well?

Thanks and Best regards,
Sumit.
> ---
>  Documentation/userspace-api/dma-buf-heaps.rst | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst
> index 05445c83b79a..f56b743cdb36 100644
> --- a/Documentation/userspace-api/dma-buf-heaps.rst
> +++ b/Documentation/userspace-api/dma-buf-heaps.rst
> @@ -16,6 +16,13 @@ following heaps:
>
>   - The ``system`` heap allocates virtually contiguous, cacheable, buffers.
>
> + - The ``system_cc_shared`` heap allocates virtually contiguous, cacheable,
> +   buffers using shared (decrypted) memory. It is only present on
> +   confidential computing (CoCo) VMs where memory encryption is active
> +   (e.g., AMD SEV, Intel TDX). The allocated pages have the encryption
> +   bit cleared, making them accessible for device DMA without TDISP
> +   support. On non-CoCo VM configurations, this heap is not registered.
> +
>   - The ``default_cma_region`` heap allocates physically contiguous,
>     cacheable, buffers. Only present if a CMA region is present. Such a
>     region is usually created either through the kernel commandline
> --
> 2.51.1
>

Re: [PATCH v2] dma-buf: heaps: system: document system_cc_shared heap

[Marek Szyprowski]

On 10.04.2026 14:14, Sumit Semwal wrote:
> On Tue, 7 Apr 2026 at 14:56, Jiri Pirko <jiri@resnulli.us> wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>>
>> Document the system_cc_shared dma-buf heap that was introduced
>> recently. Describe its purpose, availability conditions and
>> relation to confidential computing VMs.
>>
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> Reviewed-by: T.J.Mercier <tjmercier@google.com>
> Thank you for the patch!
>
> Marek: Since you're taking the dependent patches through your tree,
> could you please use:
> Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
>
> and take this as well?

Yes, sure. Applied to dma-mapping-for-next. Thanks!

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Claude review: dma-buf: heaps: system: document system_cc_shared heap

[Claude Code Review Bot]

Overall Series Review

Subject: dma-buf: heaps: system: document system_cc_shared heap
Author: Jiri Pirko <jiri@resnulli.us>
Patches: 3
Reviewed: 2026-04-12T13:56:43.989699

---

This is a single documentation-only patch (v2) that adds a description of the `system_cc_shared` dma-buf heap to the userspace API documentation. The patch is clean, well-placed, and provides useful information for userspace consumers about a CoCo-specific heap. The `system_cc_shared` heap implementation itself is not present in the drm-next tree I have access to, so this is documenting a feature introduced in a separate series.

No functional code changes. No concerns about correctness or regressions.

**Verdict: Looks good overall, with one minor wording suggestion.**

---

---
Generated by Claude Code Patch Reviewer

Claude review: dma-buf: heaps: system: document system_cc_shared heap

[Claude Code Review Bot]

Patch Review

**Placement**: Correct -- the new entry is inserted between the `system` heap and the `default_cma_region` heap, which is the natural ordering since `system_cc_shared` is a variant of the system heap.

**Content accuracy**: The description covers the key aspects:
- What it allocates (virtually contiguous, cacheable, shared/decrypted memory)
- When it's present (CoCo VMs with memory encryption active)
- Why it exists (device DMA without TDISP support)
- When it's absent (non-CoCo configurations)

**Minor wording nit**: The phrase:

```
making them accessible for device DMA without TDISP
support
```

is slightly ambiguous -- it could be parsed as "accessible for [device DMA without TDISP support]" or "accessible for device DMA, [without needing TDISP support]". Both readings arrive at the same meaning, but adding a comma would make it unambiguous:

```
making them accessible for device DMA, without requiring TDISP support.
```

This is a very minor readability suggestion, not a blocking issue.

**Naming convention**: The name `system_cc_shared` aligns well with the naming convention guidelines documented later in the same file -- it describes the memory properties (shared/decrypted for confidential computing) rather than implementation details.

**Reviewed-by**: Already has `Reviewed-by: T.J.Mercier <tjmercier@google.com>`.

**Overall**: Clean documentation patch. No objections.

---
Generated by Claude Code Patch Reviewer