All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	iommu@lists.linux.dev, linux-media@vger.kernel.org
Cc: 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, jgg@ziepe.ca, leon@kernel.org,
	sean.anderson@linux.dev, ptesarik@suse.com,
	catalin.marinas@arm.com, 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: Mon, 20 Apr 2026 12:04:06 +0530	[thread overview]
Message-ID: <yq5atst6ywbl.fsf@kernel.org> (raw)
In-Reply-To: <20260325192352.437608-2-jiri@resnulli.us>

Jiri Pirko <jiri@resnulli.us> writes:

> 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(-)
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 677c51ab7510..db8ab24a54f4 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -92,6 +92,16 @@
>   * flushing.
>   */
>  #define DMA_ATTR_REQUIRE_COHERENT	(1UL << 12)
> +/*
> + * DMA_ATTR_CC_SHARED: Indicates the DMA mapping is shared (decrypted) for
> + * confidential computing guests. For normal system memory the caller must have
> + * called set_memory_decrypted(), and pgprot_decrypted must be used when
> + * creating CPU PTEs for the mapping. The same shared semantic may be passed
> + * to the vIOMMU when it sets up the IOPTE. For MMIO use together with
> + * DMA_ATTR_MMIO to indicate shared MMIO. Unless DMA_ATTR_MMIO is provided
> + * a struct page is required.
> + */
> +#define DMA_ATTR_CC_SHARED	(1UL << 13)
>  
>  /*
>   * A dma_addr_t can hold any valid DMA or bus address for the platform.  It can
> diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h
> index 63597b004424..31c9ddf72c9d 100644
> --- a/include/trace/events/dma.h
> +++ b/include/trace/events/dma.h
> @@ -34,7 +34,8 @@ TRACE_DEFINE_ENUM(DMA_NONE);
>  		{ DMA_ATTR_PRIVILEGED, "PRIVILEGED" }, \
>  		{ DMA_ATTR_MMIO, "MMIO" }, \
>  		{ DMA_ATTR_DEBUGGING_IGNORE_CACHELINES, "CACHELINES_OVERLAP" }, \
> -		{ DMA_ATTR_REQUIRE_COHERENT, "REQUIRE_COHERENT" })
> +		{ DMA_ATTR_REQUIRE_COHERENT, "REQUIRE_COHERENT" }, \
> +		{ DMA_ATTR_CC_SHARED, "CC_SHARED" })
>  
>  DECLARE_EVENT_CLASS(dma_map,
>  	TP_PROTO(struct device *dev, phys_addr_t phys_addr, dma_addr_t dma_addr,
> diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
> index b86ff65496fc..7140c208c123 100644
> --- a/kernel/dma/direct.h
> +++ b/kernel/dma/direct.h
> @@ -89,16 +89,24 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
>  	dma_addr_t dma_addr;
>  
>  	if (is_swiotlb_force_bounce(dev)) {
> -		if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
> -			return DMA_MAPPING_ERROR;
> +		if (!(attrs & DMA_ATTR_CC_SHARED)) {
> +			if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
> +				return DMA_MAPPING_ERROR;
>  
> -		return swiotlb_map(dev, phys, size, dir, attrs);
> +			return swiotlb_map(dev, phys, size, dir, attrs);
> +		}
> +	} else if (attrs & DMA_ATTR_CC_SHARED) {
> +		return DMA_MAPPING_ERROR;
>  	}
>

What is this check for? If we are requesting a DMA mapping with
DMA_ATTR_CC_SHARED, shouldn’t it be allowed? If not, how would we reach
the conditional below where we convert the physical address to a DMA
address using phys_to_dma_unencrypted()?. Also, how is this supposed to
interact with is_swiotlb_force_bounce()?”

>  
>  	if (attrs & DMA_ATTR_MMIO) {
>  		dma_addr = phys;
>  		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
>  			goto err_overflow;
> +	} else if (attrs & DMA_ATTR_CC_SHARED) {
> +		dma_addr = phys_to_dma_unencrypted(dev, phys);
> +		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
> +			goto err_overflow;
>  	} else {
>  		dma_addr = phys_to_dma(dev, phys);
>  		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||

-aneesh

  parent reply	other threads:[~2026-04-20  6:34 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
2026-04-20  6:34     ` Aneesh Kumar K.V [this message]
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=yq5atst6ywbl.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=Brian.Starkey@arm.com \
    --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=jgg@ziepe.ca \
    --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.