From: Aneesh Kumar K.V <aneesh.kumar@kernel•org>
To: Michael Kelley <mhklinux@outlook•com>,
Jason Gunthorpe <jgg@ziepe•ca>,
Michael Kelley <mhklinux@outlook•com>
Cc: "iommu@lists•linux.dev" <iommu@lists•linux.dev>,
"linux-arm-kernel@lists•infradead.org"
<linux-arm-kernel@lists•infradead.org>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
"linux-coco@lists•linux.dev" <linux-coco@lists•linux.dev>,
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>,
Mostafa Saleh <smostafa@google•com>,
Petr Tesarik <ptesarik@suse•com>,
Alexey Kardashevskiy <aik@amd•com>,
Dan Williams <dan.j.williams@intel•com>,
Xu Yilun <yilun.xu@linux•intel.com>,
"linuxppc-dev@lists•ozlabs.org" <linuxppc-dev@lists•ozlabs.org>,
"linux-s390@vger•kernel.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" <x86@kernel•org>, Jiri Pirko <jiri@nvidia•com>
Subject: RE: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
Date: Thu, 04 Jun 2026 20:27:36 +0530 [thread overview]
Message-ID: <yq5apl26qrof.fsf@kernel.org> (raw)
In-Reply-To: <SN6PR02MB4157F94C902B78E55E99372DD4102@SN6PR02MB4157.namprd02.prod.outlook.com>
Michael Kelley <mhklinux@outlook•com> writes:
> From: Jason Gunthorpe <jgg@ziepe•ca> Sent: Tuesday, June 2, 2026 5:55 PM
>>
>> On Tue, Jun 02, 2026 at 02:24:40PM +0000, Michael Kelley wrote:
>>
>> > Except that in a normal VM, the "unencrypted" pool attribute does *not*
>> > describe the state of the memory itself. In a normal VM, the memory is
>> > unencrypted, but the "unencrypted" pool attribute is false. That
>> > contradiction is the essence of my concern.
>>
>> I would argue no..
>>
>> When CC is enabled the default state of memory in a Linux environment
>> is "encrypted". You have to take a special action to "decrypt" it.
>>
>> Thus the default state of memory in a non-CC environment is also
>> paradoxically "encrypted" too.
>
> The need to have such an unnatural premise is usually an indication
> of a conceptual problem with the overall model, or perhaps just a
> terminology problem.
>
> Here's a proposal. The new DMA attribute is DMA_ATTR_CC_SHARED.
> Name the pool attribute "cc_shared" instead of "unencrypted". Having
> "cc_shared" set to false in a normal VM doesn't lead to the non-sensical
> situation of claiming that a normal VM is encrypted. The boolean
> "unencrypted" parameter that has been added to various calls also
> becomes "cc_shared". If "CC_SHARED" is a suitable name for the DMA
> attribute, it ought to be suitable as the pool attribute. And everything
> matches as well.
>
That is better. It would also simplify:
if (mem->unencrypted != !!(attrs & DMA_ATTR_CC_SHARED))
return NULL;
to
if (mem->cc_shared != !!(attrs & DMA_ATTR_CC_SHARED))
return NULL;
I already sent a v6 in the hope of getting this merged for the next
merge window. Should I send a v7, or would you prefer that I do the
rename on top of v6?
-aneesh
next prev parent reply other threads:[~2026-06-04 14:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 4:27 [PATCH v5 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths Aneesh Kumar K.V (Arm)
2026-05-22 4:27 ` [PATCH v5 01/20] [DO NOT MERGE] arm64/coco: Add pKVM as a CC platform Aneesh Kumar K.V (Arm)
2026-05-22 4:27 ` [PATCH v5 02/20] [DO NOT MERGE] s390: Expose protected virtualization through cc_platform_has() Aneesh Kumar K.V (Arm)
2026-05-22 15:35 ` JAEHOON KIM
2026-05-22 4:27 ` [PATCH v5 03/20] dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages Aneesh Kumar K.V (Arm)
2026-05-22 4:27 ` [PATCH v5 04/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs Aneesh Kumar K.V (Arm)
2026-05-28 18:29 ` Michael Kelley
2026-06-02 6:05 ` Aneesh Kumar K.V
2026-06-02 14:24 ` Michael Kelley
2026-06-03 0:54 ` Jason Gunthorpe
2026-06-04 14:05 ` Michael Kelley
2026-06-04 14:30 ` Jason Gunthorpe
2026-06-04 14:57 ` Aneesh Kumar K.V [this message]
2026-06-04 16:18 ` Michael Kelley
2026-06-04 18:24 ` Jason Gunthorpe
2026-05-22 4:28 ` [PATCH v5 06/20] dma: swiotlb: pass mapping attributes by reference Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 07/20] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 08/20] dma-mapping: make dma_pgprot() " Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 09/20] dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 10/20] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-26 2:56 ` Michael Kelley
2026-05-26 15:39 ` Jason Gunthorpe
2026-06-02 6:10 ` Aneesh Kumar K.V
2026-05-22 4:28 ` [PATCH v5 11/20] dma-direct: set decrypted flag for remapped DMA allocations Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 12/20] dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 13/20] dma-pool: fix page leak in atomic_pool_expand() cleanup Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 14/20] dma-direct: rename ret to cpu_addr in alloc helpers Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 15/20] dma-direct: return struct page from dma_direct_alloc_from_pool() Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 16/20] iommu/dma: Check atomic pool allocation result directly Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 17/20] dma: swiotlb: free dynamic pools from process context Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 18/20] dma: swiotlb: handle set_memory_decrypted() failures Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 19/20] dma: free atomic pool pages by physical address Aneesh Kumar K.V (Arm)
2026-05-22 4:28 ` [PATCH v5 20/20] swiotlb: Preserve allocation virtual address for dynamic pools Aneesh Kumar K.V (Arm)
2026-05-26 4:30 ` [PATCH v5 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths Michael Kelley
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=yq5apl26qrof.fsf@kernel.org \
--to=aneesh.kumar@kernel$(echo .)org \
--cc=Suzuki.Poulose@arm$(echo .)com \
--cc=agordeev@linux$(echo .)ibm.com \
--cc=aik@amd$(echo .)com \
--cc=borntraeger@linux$(echo .)ibm.com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=chleroy@kernel$(echo .)org \
--cc=dan.j.williams@intel$(echo .)com \
--cc=gerald.schaefer@linux$(echo .)ibm.com \
--cc=gor@linux$(echo .)ibm.com \
--cc=hca@linux$(echo .)ibm.com \
--cc=iommu@lists$(echo .)linux.dev \
--cc=jgg@ziepe$(echo .)ca \
--cc=jiri@nvidia$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-coco@lists$(echo .)linux.dev \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-s390@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=m.szyprowski@samsung$(echo .)com \
--cc=maddy@linux$(echo .)ibm.com \
--cc=maz@kernel$(echo .)org \
--cc=mhklinux@outlook$(echo .)com \
--cc=mpe@ellerman$(echo .)id.au \
--cc=npiggin@gmail$(echo .)com \
--cc=ptesarik@suse$(echo .)com \
--cc=robin.murphy@arm$(echo .)com \
--cc=smostafa@google$(echo .)com \
--cc=steven.price@arm$(echo .)com \
--cc=svens@linux$(echo .)ibm.com \
--cc=will@kernel$(echo .)org \
--cc=x86@kernel$(echo .)org \
--cc=yilun.xu@linux$(echo .)intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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