Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Alexey Kardashevskiy <aik@amd.com>,
	iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev
Cc: Robin Murphy <robin.murphy@arm.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Steven Price <steven.price@arm.com>,
	Suzuki K Poulose <Suzuki.Poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jiri Pirko <jiri@resnulli.us>, Jason Gunthorpe <jgg@ziepe.ca>,
	Mostafa Saleh <smostafa@google.com>,
	Petr Tesarik <ptesarik@suse.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Xu Yilun <yilun.xu@linux.intel.com>,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	x86@kernel.org
Subject: Re: [PATCH v4 03/13] dma-pool: track decrypted atomic pools and select them via attrs
Date: Mon, 18 May 2026 14:02:55 +0530	[thread overview]
Message-ID: <yq5ajyt1xglk.fsf@kernel.org> (raw)
In-Reply-To: <df4b78cf-6192-4fe3-8ad5-df9e6fdda8e6@amd.com>

Alexey Kardashevskiy <aik@amd.com> writes:

> On 16/5/26 22:53, Alexey Kardashevskiy wrote:
>> On 12/5/26 19:03, Aneesh Kumar K.V (Arm) wrote:

...

>>> -static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>>> +static int atomic_pool_expand(struct dma_gen_pool *dma_pool, size_t pool_size,
>>>                     gfp_t gfp)
>>>   {
>>>       unsigned int order;
>>> @@ -113,12 +119,15 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>>>        * Memory in the atomic DMA pools must be unencrypted, the pools do not
>>>        * shrink so no re-encryption occurs in dma_direct_free().
>>>        */
>>> -    ret = set_memory_decrypted((unsigned long)page_to_virt(page),
>>> +    if (dma_pool->unencrypted) {
>>> +        ret = set_memory_decrypted((unsigned long)page_to_virt(page),
>>>                      1 << order);
>>> -    if (ret)
>>> -        goto remove_mapping;
>>> -    ret = gen_pool_add_virt(pool, (unsigned long)addr, page_to_phys(page),
>>> -                pool_size, NUMA_NO_NODE);
>>> +        if (ret)
>>> +            goto remove_mapping;
>>> +    }
>>> +
>>> +    ret = gen_pool_add_virt(dma_pool->pool, (unsigned long)addr,
>>> +                page_to_phys(page), pool_size, NUMA_NO_NODE);
>
>
> This clause could go to the else branch.
>
>

Can you clarify this better? 

>>>       if (ret)
>>>           goto encrypt_mapping;
>>> @@ -126,11 +135,15 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>>>       return 0;
>>>   encrypt_mapping:
>>> -    ret = set_memory_encrypted((unsigned long)page_to_virt(page),
>>> -                   1 << order);
>>> -    if (WARN_ON_ONCE(ret)) {
>>> -        /* Decrypt succeeded but encrypt failed, purposely leak */
>>> -        goto out;
>>> +    if (dma_pool->unencrypted) {
>>> +        int rc;
>>> +
>>> +        rc = set_memory_encrypted((unsigned long)page_to_virt(page),
>>> +                      1 << order);
>>> +        if (WARN_ON_ONCE(rc)) {
>>> +            /* Decrypt succeeded but encrypt failed, purposely leak */
>>> +            goto out;
>>> +        }
>>>       }
>>>   remove_mapping:
>>>   #ifdef CONFIG_DMA_DIRECT_REMAP
>>> @@ -142,46 +155,52 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>>>       return ret;
>>>   }

...

>>>   bool dma_free_from_pool(struct device *dev, void *start, size_t size)
>>>   {
>>> -    struct gen_pool *pool = NULL;
>>> +    struct dma_gen_pool *dma_pool = NULL;
>>> +
>>> +    while ((dma_pool = dma_guess_pool(dma_pool, 0))) {
>>> -    while ((pool = dma_guess_pool(pool, 0))) {
>>> -        if (!gen_pool_has_addr(pool, (unsigned long)start, size))
>>> +        if (!gen_pool_has_addr(dma_pool->pool, (unsigned long)start, size))
>> 
>> 
>> v3 of this just crashed here with dma_pool!=NULL but dma_pool->pool==NULL. continuing debugging... Thanks,
>
>
> dma_direct_free:
>    dma_free_from_pool (loop over pools) -> false
>      [here was a crash which I fixed by "if (!dma_pool->pool) continue"]
>    swiotlb_find_pool (loop again) -> false
>      __dma_direct_free_pages
>        swiotlb_free
>          swiotlb_find_pool (loop again)
>        dma_free_contiguous => done.
>
> so that works but kinda hard to follow and there is some room for
> optimization. I do not normally have swiottlb when I test this and
> there is too many of this swiotlb stuff on the real direct dma mapping
> path imho. Thanks,
>

I will work on this in the next update. I can possibly drop the
swiotlb_find_pool from the swiotlb_free() path.

>> 
>> 
>>>               continue;
>>> -        gen_pool_free(pool, (unsigned long)start, size);
>>> +
>>> +        gen_pool_free(dma_pool->pool, (unsigned long)start, size);
>>>           return true;
>>>       }
>>> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
>>> index 1abd3e6146f4..ab4eccbaa076 100644
>>> --- a/kernel/dma/swiotlb.c
>>> +++ b/kernel/dma/swiotlb.c
>>> @@ -612,6 +612,7 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
>>>           u64 phys_limit, gfp_t gfp)
>>>   {
>>>       struct page *page;
>>> +    unsigned long attrs = 0;
>>>       /*
>>>        * Allocate from the atomic pools if memory is encrypted and
>>> @@ -623,8 +624,12 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
>>>           if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
>>>               return NULL;
>>> +        /* swiotlb considered decrypted by default */
>>> +        if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>>> +            attrs = DMA_ATTR_CC_SHARED;
>>> +
>>>           return dma_alloc_from_pool(dev, bytes, &vaddr, gfp,
>>> -                       dma_coherent_ok);
>>> +                       attrs, dma_coherent_ok);
>>>       }
>>>       gfp &= ~GFP_ZONEMASK;
>> 
>
> -- 
> Alexey


-aneesh

  reply	other threads:[~2026-05-18  8:33 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12  9:03 [PATCH v4 00/13] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths Aneesh Kumar K.V (Arm)
2026-05-12  9:03 ` [PATCH v4 01/13] dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages Aneesh Kumar K.V (Arm)
2026-05-13 13:57   ` Mostafa Saleh
2026-05-14  4:54     ` Aneesh Kumar K.V
2026-05-12  9:03 ` [PATCH v4 02/13] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths Aneesh Kumar K.V (Arm)
2026-05-13 13:58   ` Mostafa Saleh
2026-05-14  5:01     ` Aneesh Kumar K.V
2026-05-12  9:03 ` [PATCH v4 03/13] dma-pool: track decrypted atomic pools and select them via attrs Aneesh Kumar K.V (Arm)
2026-05-13 14:00   ` Mostafa Saleh
2026-05-14  7:00     ` Aneesh Kumar K.V
2026-05-14  8:06       ` Mostafa Saleh
2026-05-16 12:53   ` Alexey Kardashevskiy
2026-05-18  8:19     ` Alexey Kardashevskiy
2026-05-18  8:32       ` Aneesh Kumar K.V [this message]
2026-05-12  9:03 ` [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-13 14:27   ` Mostafa Saleh
2026-05-13 17:24     ` Jason Gunthorpe
2026-05-14  6:24       ` Aneesh Kumar K.V
2026-05-14 11:48       ` Mostafa Saleh
2026-05-14 12:35         ` Jason Gunthorpe
2026-05-14 14:43           ` Mostafa Saleh
2026-05-15 22:51             ` Jason Gunthorpe
2026-05-19 11:06               ` Mostafa Saleh
2026-05-19 13:39                 ` Jason Gunthorpe
2026-05-14  5:54     ` Aneesh Kumar K.V
2026-05-14 12:02       ` Mostafa Saleh
2026-05-14 12:48         ` Aneesh Kumar K.V
2026-05-14 14:21           ` Mostafa Saleh
2026-05-14 14:43             ` Aneesh Kumar K.V
2026-05-19 11:04               ` Mostafa Saleh
2026-05-19 12:27                 ` Aneesh Kumar K.V
2026-05-19 15:07                   ` Aneesh Kumar K.V
2026-05-19 15:27                     ` Jason Gunthorpe
2026-05-19 16:05                       ` Aneesh Kumar K.V
2026-05-19 16:11                         ` Jason Gunthorpe
2026-05-19 13:29                 ` Jason Gunthorpe
2026-05-19 13:41                   ` Mostafa Saleh
2026-05-19 14:00                     ` Aneesh Kumar K.V
2026-05-19 14:04                       ` Mostafa Saleh
2026-05-19 14:17                         ` Aneesh Kumar K.V
2026-05-19 14:27                           ` Mostafa Saleh
2026-05-19 14:37                             ` Jason Gunthorpe
2026-05-19 14:35                     ` Jason Gunthorpe
2026-05-19 14:45                       ` Mostafa Saleh
2026-05-19 14:49                         ` Jason Gunthorpe
2026-05-14 14:37           ` Jason Gunthorpe
2026-05-14 15:43             ` Mostafa Saleh
2026-05-18  8:19   ` Alexey Kardashevskiy
2026-05-12  9:04 ` [PATCH v4 05/13] dma-mapping: make dma_pgprot() " Aneesh Kumar K.V (Arm)
2026-05-12  9:04 ` [PATCH v4 06/13] dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks Aneesh Kumar K.V (Arm)
2026-05-12  9:04 ` [PATCH v4 07/13] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-18 10:04   ` Christian Borntraeger
2026-05-12  9:04 ` [PATCH v4 08/13] dma-direct: set decrypted flag for remapped DMA allocations Aneesh Kumar K.V (Arm)
2026-05-12  9:04 ` [PATCH v4 09/13] dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-12  9:04 ` [PATCH v4 10/13] dma-pool: fix page leak in atomic_pool_expand() cleanup Aneesh Kumar K.V (Arm)
2026-05-12  9:04 ` [PATCH v4 11/13] dma-direct: rename ret to cpu_addr in alloc helpers Aneesh Kumar K.V (Arm)
2026-05-12  9:04 ` [PATCH v4 12/13] dma-direct: return struct page from dma_direct_alloc_from_pool() Aneesh Kumar K.V (Arm)
2026-05-12  9:04 ` [PATCH v4 13/13] x86/amd-gart: preserve the direct DMA address until GART mapping succeeds Aneesh Kumar K.V (Arm)
2026-05-17  6:19 ` [PATCH v4 00/13] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths Jiri Pirko
2026-05-18  8:23   ` Aneesh Kumar K.V
2026-05-18  8:34     ` 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=yq5ajyt1xglk.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=Suzuki.Poulose@arm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=aik@amd.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=chleroy@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jiri@resnulli.us \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maddy@linux.ibm.com \
    --cc=maz@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=ptesarik@suse.com \
    --cc=robin.murphy@arm.com \
    --cc=smostafa@google.com \
    --cc=steven.price@arm.com \
    --cc=svens@linux.ibm.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yilun.xu@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox