public inbox for iommu@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Mostafa Saleh <smostafa@google.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org,
	maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com,
	jiri@resnulli.us, jgg@ziepe.ca
Subject: Re: [RFC PATCH v3 1/5] swiotlb: Return state of memory from swiotlb_alloc()
Date: Fri, 17 Apr 2026 15:05:05 +0000	[thread overview]
Message-ID: <aeJMIel-A26QtX6s@google.com> (raw)
In-Reply-To: <yq5aeckf9thn.fsf@kernel.org>

On Thu, Apr 16, 2026 at 02:23:08PM +0530, Aneesh Kumar K.V wrote:
> Mostafa Saleh <smostafa@google.com> writes:
> 
> > On Tue, Apr 14, 2026 at 02:55:33PM +0530, Aneesh Kumar K.V wrote:
> >> Mostafa Saleh <smostafa@google.com> writes:
> >> 
> >> > Make swiotlb_alloc() return the state of the allocated memory, at
> >> > the moment all the pools are decrypted but that would change soon.
> >> > In the next patches dma-direct will use the returned state to
> >> > determine whether to decrypt the memory and use the proper memory
> >> > decryption/encryption related functions.
> >> >
> >> > Also, add swiotlb_is_decrypted(), that will be used before calling
> >> > swiotlb_free() to check whether the memory needs to be encrypted
> >> > by the caller.
> >> >
> >> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> >> > ---
> >> >  include/linux/swiotlb.h | 25 +++++++++++++++++++++++--
> >> >  kernel/dma/direct.c     |  2 +-
> >> >  kernel/dma/swiotlb.c    | 23 ++++++++++++++++++++++-
> >> >  3 files changed, 46 insertions(+), 4 deletions(-)
> >> >
> >> > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> >> > index 3dae0f592063..24be65494ce8 100644
> >> > --- a/include/linux/swiotlb.h
> >> > +++ b/include/linux/swiotlb.h
> >> > @@ -63,6 +63,7 @@ extern void __init swiotlb_update_mem_attributes(void);
> >> >   * @area_nslabs: Number of slots in each area.
> >> >   * @areas:	Array of memory area descriptors.
> >> >   * @slots:	Array of slot descriptors.
> >> > + * @decrypted:	Whether the pool was decrypted or left in default state.
> >> >   * @node:	Member of the IO TLB memory pool list.
> >> >   * @rcu:	RCU head for swiotlb_dyn_free().
> >> >   * @transient:  %true if transient memory pool.
> >> > @@ -77,6 +78,7 @@ struct io_tlb_pool {
> >> >  	unsigned int area_nslabs;
> >> >  	struct io_tlb_area *areas;
> >> >  	struct io_tlb_slot *slots;
> >> > +	bool decrypted;
> >> >  #ifdef CONFIG_SWIOTLB_DYNAMIC
> >> >  	struct list_head node;
> >> >  	struct rcu_head rcu;
> >> > @@ -281,16 +283,31 @@ static inline void swiotlb_sync_single_for_cpu(struct device *dev,
> >> >
> >> 
> >> Should this be a property of struct io_tlb_mem ? 
> >
> > I envisioned that this would be mainly used by restricted-dma so in
> > that case it doesn’t seem to matter.
> > But generally, I guess it would depend on the discovery mechanism of
> > this memory property and I can imagine a memory allocator that has
> > multiple pools with different attributes. So propably it's better to
> > be per pool.
> >
> 
> If we are going to make this generic, we may not be able to look at only
> restricted-dma. Instead, we will have to consider other SWIOTLB code
> paths as well, such as swiotlb_map(), swiotlb_alloc_pool() etc. For
> example, in swiotlb_dyn_alloc(), how do we determine whether to use
> decrypted or encrypted memory? I am thinking we want to use struct
> io_tlb_mem.decrypted field to determine that
> 
> 	struct io_tlb_mem *mem =
> 		container_of(work, struct io_tlb_mem, dyn_alloc);
> 
> 	pool = swiotlb_alloc_pool(NULL, IO_TLB_MIN_SLABS, default_nslabs,
> 				  default_nareas, mem->phys_limit, mem->decrypted,
> 				  GFP_KERNEL);
> 
> 
> Also, for things like swiotlb_tbl_map_single(), we might want to …
> 
> 	struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> 
> 	/* if phys addr attribute is encrypted but the device is forcing an encrypted dma addr */
> 	if (!(attrs & DMA_ATTR_CC_DECRYPTED) && force_dma_unencrypted(dev))
> 		require_decrypted = true;
> 
> 	if (require_decrypted != mem->decrypted)
> 		return (phys_addr_t)DMA_MAPPING_ERROR;



I guess that depends on the discovery mechanism, I was thinking
restricted-dma pools can represent that from firmware as device tree
binding.

For SWIOTLB, I am not really sure how that works, as they are shared by
all devices on the system. I was thinking it remains decrypted as it is
typically used by simple devices that doesn't deal with encrypted memory
and devices that require special pools (whether decrypted or encrypted)
they would use restricted-dma.

Thanks,
Mostafa

> 
> -aneesh

  reply	other threads:[~2026-04-17 15:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 19:47 [RFC PATCH v3 0/5] dma-mapping: Fixes for memory encryption Mostafa Saleh
2026-04-08 19:47 ` [RFC PATCH v3 1/5] swiotlb: Return state of memory from swiotlb_alloc() Mostafa Saleh
2026-04-14  9:25   ` Aneesh Kumar K.V
2026-04-15 20:43     ` Mostafa Saleh
2026-04-16  8:53       ` Aneesh Kumar K.V
2026-04-17 15:05         ` Mostafa Saleh [this message]
2026-04-08 19:47 ` [RFC PATCH v3 2/5] dma-mapping: Move encryption in __dma_direct_free_pages() Mostafa Saleh
2026-04-10 17:45   ` Jason Gunthorpe
2026-04-15 20:49     ` Mostafa Saleh
2026-04-16  0:11       ` Jason Gunthorpe
2026-04-17 15:07         ` Mostafa Saleh
2026-04-08 19:47 ` [RFC PATCH v3 3/5] dma-mapping: Decrypt memory on remap Mostafa Saleh
2026-04-14  9:31   ` Aneesh Kumar K.V
2026-04-14 12:22     ` Jason Gunthorpe
2026-04-14 13:13       ` Aneesh Kumar K.V
2026-04-14 13:53         ` Jason Gunthorpe
2026-04-08 19:47 ` [RFC PATCH v3 4/5] dma-mapping: Encapsulate memory state during allocation Mostafa Saleh
2026-04-10 18:05   ` Jason Gunthorpe
2026-04-15  9:38     ` Aneesh Kumar K.V
2026-04-17 15:45     ` Mostafa Saleh
2026-04-08 19:47 ` [RFC PATCH v3 5/5] dma-mapping: Fix memory decryption issues Mostafa Saleh
2026-04-13  7:19   ` Aneesh Kumar K.V
2026-04-13 12:42     ` Jason Gunthorpe
2026-04-15 12:43       ` Aneesh Kumar K.V
2026-04-15 13:53         ` Jason Gunthorpe
2026-04-14  9:37   ` Aneesh Kumar K.V
2026-04-10 17:43 ` [RFC PATCH v3 0/5] dma-mapping: Fixes for memory encryption Jason Gunthorpe
2026-04-15 20:25   ` Mostafa Saleh

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=aeJMIel-A26QtX6s@google.com \
    --to=smostafa@google.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jiri@resnulli.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maz@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@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