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

Aneesh Kumar K.V
2026-04-16T08:53:14Z

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;

-aneesh