From: Jason Gunthorpe <jgg@nvidia.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
iommu@lists.linux.dev, linux-media@vger.kernel.org,
sumit.semwal@linaro.org, benjamin.gaignard@collabora.com,
Brian.Starkey@arm.com, jstultz@google.com, tjmercier@google.com,
christian.koenig@amd.com, m.szyprowski@samsung.com,
robin.murphy@arm.com, leon@kernel.org, sean.anderson@linux.dev,
ptesarik@suse.com, catalin.marinas@arm.com,
aneesh.kumar@kernel.org, suzuki.poulose@arm.com,
steven.price@arm.com, thomas.lendacky@amd.com,
john.allen@amd.com, ashish.kalra@amd.com,
suravee.suthikulpanit@amd.com, linux-coco@lists.linux.dev
Subject: Re: [PATCH v5 1/2] dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory
Date: Tue, 31 Mar 2026 12:08:08 -0300 [thread overview]
Message-ID: <20260331150808.GA2308548@nvidia.com> (raw)
In-Reply-To: <20260325192352.437608-2-jiri@resnulli.us>
On Wed, Mar 25, 2026 at 08:23:51PM +0100, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@nvidia.com>
>
> 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
> shared memory on behalf of the device.
>
> When a caller has already arranged for the memory to be shared
> 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_SHARED 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 <jiri@nvidia.com>
> ---
> v4->v5:
> - rebased on top od dma-mapping-for-next
> - s/decrypted/shared/
> v3->v4:
> - added some sanity checks to dma_map_phys and dma_unmap_phys
> - enhanced documentation of DMA_ATTR_CC_DECRYPTED attr
> v1->v2:
> - rebased on top of recent dma-mapping-fixes
> ---
> include/linux/dma-mapping.h | 10 ++++++++++
> include/trace/events/dma.h | 3 ++-
> kernel/dma/direct.h | 14 +++++++++++---
> kernel/dma/mapping.c | 13 +++++++++++--
> 4 files changed, 34 insertions(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
next prev parent reply other threads:[~2026-03-31 15:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260325192400eucas1p2ae38ff4c2b3ab35a7047cfd680d9fda3@eucas1p2.samsung.com>
2026-03-25 19:23 ` [PATCH v5 0/2] dma-buf: heaps: system: add an option to allocate explicitly shared/decrypted memory Jiri Pirko
2026-03-25 19:23 ` [PATCH v5 1/2] dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory Jiri Pirko
2026-03-31 15:08 ` Jason Gunthorpe [this message]
2026-04-20 6:34 ` Aneesh Kumar K.V
2026-04-20 9:29 ` Jiri Pirko
2026-04-21 9:42 ` Aneesh Kumar K.V
2026-04-21 11:53 ` Jiri Pirko
2026-04-21 12:10 ` Jason Gunthorpe
2026-04-22 7:51 ` Petr Tesarik
2026-04-22 9:18 ` Aneesh Kumar K.V
2026-04-24 22:55 ` Jason Gunthorpe
2026-04-26 13:05 ` Jason Gunthorpe
2026-03-25 19:23 ` [PATCH v5 2/2] dma-buf: heaps: system: add system_cc_shared heap for explicitly " Jiri Pirko
2026-03-27 19:43 ` T.J. Mercier
2026-03-31 15:08 ` Jason Gunthorpe
2026-04-02 12:23 ` Maxime Ripard
2026-04-02 12:56 ` Jiri Pirko
2026-03-27 9:38 ` [PATCH v5 0/2] dma-buf: heaps: system: add an option to allocate explicitly shared/decrypted memory Marek Szyprowski
2026-03-27 12:10 ` Jason Gunthorpe
2026-03-27 19:43 ` T.J. Mercier
2026-04-02 4:41 ` Sumit Semwal
2026-04-02 5:35 ` Marek Szyprowski
2026-04-02 9:52 ` Brian Starkey
2026-04-02 12:02 ` Jason Gunthorpe
2026-04-02 12:58 ` Jiri Pirko
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=20260331150808.GA2308548@nvidia.com \
--to=jgg@nvidia.com \
--cc=Brian.Starkey@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=ashish.kalra@amd.com \
--cc=benjamin.gaignard@collabora.com \
--cc=catalin.marinas@arm.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=jiri@resnulli.us \
--cc=john.allen@amd.com \
--cc=jstultz@google.com \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=ptesarik@suse.com \
--cc=robin.murphy@arm.com \
--cc=sean.anderson@linux.dev \
--cc=steven.price@arm.com \
--cc=sumit.semwal@linaro.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=suzuki.poulose@arm.com \
--cc=thomas.lendacky@amd.com \
--cc=tjmercier@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.