Re: [RFC PATCH v3 1/5] swiotlb: Return state of memory from swiotlb_alloc()

[Aneesh Kumar K . V]

Mostafa Saleh <smostafa@xxxxxxxxxx> writes:

> On Tue, Apr 14, 2026 at 02:55:33PM +0530, Aneesh Kumar K.V wrote:
>> Mostafa Saleh <smostafa@xxxxxxxxxx> 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@xxxxxxxxxx>
>> > ---
>> >  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;

-aneesh