From: Mostafa Saleh <smostafa@google.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, 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>, Jason Gunthorpe <jgg@ziepe.ca>,
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, 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 v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths
Date: Tue, 28 Jul 2026 14:22:04 +0000 [thread overview]
Message-ID: <ami7DMIlYHbcEt_6@google.com> (raw)
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
On Fri, Jul 17, 2026 at 11:34:18PM +0530, Aneesh Kumar K.V (Arm) wrote:
> This series tracks confidential-computing shared DMA state through the
> dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted
> DMA buffers are handled consistently.
>
> Today, the direct DMA path mostly relies on force_dma_unencrypted() for
> shared/decrypted buffer handling. This series consolidates the
> force_dma_unencrypted() checks in the top-level functions and ensures
> that the remaining DMA interfaces use DMA attributes to make the correct
> decisions.
>
> The series separates mapping and allocation state:
> - DMA_ATTR_CC_SHARED describes the DMA address attribute requested for a
> mapping. It tells the DMA mapping path that the DMA address must target
> shared/decrypted memory.
> - __DMA_ATTR_ALLOC_CC_SHARED is an internal DMA-mapping attribute used only
> by allocation paths after the DMA core decides that the backing pages
> must be allocated as shared/decrypted memory.
>
> The series:
> - moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
> - uses __DMA_ATTR_ALLOC_CC_SHARED through the dma-direct alloc/free paths
> - teaches the atomic DMA pools to track encrypted versus decrypted
> state
> - tracks swiotlb pool encryption state and enforces strict pool
> selection
> - centralizes encrypted/decrypted pgprot handling in dma_pgprot() using
> DMA attributes
> - passes DMA attributes down to dma_capable() so capability checks can
> validate whether the selected DMA address encoding matches
> DMA_ATTR_CC_SHARED
> - makes dma_direct_map_phys() choose the DMA address encoding from
> DMA_ATTR_CC_SHARED and fall back to swiotlb when a shared DMA request
> cannot use the direct mapping, which lets arm64 and x86 CCA guests stop
> relying on SWIOTLB_FORCE for DMA mappings
> - use the selected swiotlb pool state to derive the returned DMA
> address
> - reports CC_ATTR_GUEST_MEM_ENCRYPT for arm64 Realms, powerpc secure
> guests, and s390 protected virtualization guests.
>
This series has been getting bigger, going through it again, I see
that patches (1, 2, 3, 4, 5, 16, 20, 22) are not really related to the
shared DMA work and are either fixes for exisiting bugs or clean ups.
Would it make sense to have those separated?
Thanks,
Mostafa
> Dependency:
> This series depends on the pKVM changes posted at:
> https://lore.kernel.org/all/20260603110522.3331819-1-smostafa@google.com
>
> Please merge this series only after the pKVM changes above are merged.
> Otherwise pKVM will be broken.
>
> Changes since v7:
> https://lore.kernel.org/all/20260701054926.825925-1-aneesh.kumar@kernel.org
> * Rebased onto dma-mapping-for-next
> * Prepared the series on top of the prerequisite pKVM changes, resolving
> conflicts so it can be applied directly to the pKVM topic branch once ready.
> https://git.gitlab.arm.com/linux-arm/linux-cca/-/commits/scratch/pkvm/testing
> * Added comments documenting possible follow-up improvements for CC_SHARED
> atomic pools and physical-address-based pool freeing.
> * Retained virtual-address-based pool freeing when
> CONFIG_DMA_DIRECT_REMAP is disabled.
> * Applied pgprot_decrypted() only when expanding a CC_SHARED atomic pool.
>
> Changes since v6:
> https://lore.kernel.org/all/20260604083959.1265923-1-aneesh.kumar@kernel.org
> * Rebase onto the latest kernel.
> * Add __DMA_ATTR_ALLOC_CC_SHARED for allocation paths. DMA_ATTR_CC_SHARED
> is now used to describe the requested DMA mapping address attribute,
> while __DMA_ATTR_ALLOC_CC_SHARED is used internally when allocating
> shared/decrypted backing pages.
> * Report CC_ATTR_GUEST_MEM_ENCRYPT for arm64 Realms, powerpc secure
> guests, and s390 protected virtualization guests.
> * Add CC_ATTR_HOST_MEM_ENCRYPT and swiotlb=force fixes.
>
> Changes since v5:
> https://lore.kernel.org/all/20260522042815.370873-1-aneesh.kumar@kernel.org
> * Add Tested-by
> * Drop the pKVM patch, which has now been posted separately:
> https://lore.kernel.org/all/20260603110522.3331819-1-smostafa@google.com
> * Remove the DO_NOT_MERGE tag from the s390 change.
> * Add a patch to drop the SWIOTLB_FORCE flag.
> * Rebase onto the latest kernel.
>
> Changes since v4:
> https://lore.kernel.org/all/20260512090408.794195-1-aneesh.kumar@kernel.org
> * Add new patches based on Sashiko review:
> swiotlb: Preserve allocation virtual address for dynamic pools
> dma: free atomic pool pages by physical address
> dma: swiotlb: handle set_memory_decrypted() failures
> dma: swiotlb: free dynamic pools from process context
> iommu/dma: Check atomic pool allocation result directly
> * Include pKVM and s390 changes as dependent patches. These are not yet
> ready to merge and are waiting for subsystem testing feedback.
> * Drop the AMD GART patch because it requires wider testing.
> * Update swiotlb_tbl_map_single() to take attrs by reference.
> * Switch swiotlb_free() to use rcu_work.
> * Avoid calling swiotlb_find_pool() multiple times in the free path.
> * Make DMA_ATTR_MMIO imply DMA_ATTR_CC_SHARED for devices requiring unencrypted DMA.
>
> Changes from v3:
> https://lore.kernel.org/all/20260427055509.898190-1-aneesh.kumar@kernel.org
> * Handle DMA_ATTR_MMIO correctly in dma_direct_map_phys()
> * Address most of sashiko review
> * Rebase to latest kernel
> * drop SWIOTLB_FORCE for s390 and powerpc secure guest.
>
> Changes from v2:
> https://lore.kernel.org/all/20260420061415.3650870-1-aneesh.kumar@kernel.org
> * pass attrs to dma_capable() and update direct, swiotlb, Xen swiotlb, and
> x86 GART paths so the capability checks see the DMA address attr value
> DMA_ATTR_CC_SHARED.
> * rework dma_direct_map_phys() so DMA_ATTR_CC_SHARED selects
> phys_to_dma_unencrypted() while the default path uses
> phys_to_dma_encrypted(), with swiotlb fallback when the requested
> shared/private state cannot be satisfied by a direct DMA address.
> * stop relying on SWIOTLB_FORCE for arm64 and x86 CC guest DMA mappings;
> swiotlb is still enabled there, but shared mappings is now selected
> through the generic dma_direct_map_phys()/dma_capable() decision instead
> of a global force-bounce flag.
>
> Changes from v1:
> https://lore.kernel.org/all/20260417085900.3062416-1-aneesh.kumar@kernel.org
> * rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
> * update the alloc path so DMA_ATTR_CC_SHARED is not a caller-visible attribute.
>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Mostafa Saleh <smostafa@google.com>
> Cc: Petr Tesarik <ptesarik@suse.com>
> Cc: Alexey Kardashevskiy <aik@amd.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Xu Yilun <yilun.xu@linux.intel.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s390@vger.kernel.org
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
> Cc: Sven Schnelle <svens@linux.ibm.com>
> Cc: x86@kernel.org
>
> Aneesh Kumar K.V (Arm) (23):
> dma-direct: return struct page from dma_direct_alloc_from_pool()
> dma-pool: fix page leak in atomic_pool_expand() cleanup
> iommu/dma: Check atomic pool allocation result directly
> dma: free atomic pool pages by physical address
> swiotlb: Preserve allocation virtual address for dynamic pools
> s390: Expose protected virtualization through cc_platform_has()
> dma-direct: swiotlb: handle swiotlb alloc/free outside
> __dma_direct_alloc_pages
> coco: arm64: s390: powerpc: Mark secure guests with
> CC_ATTR_GUEST_MEM_ENCRYPT
> dma-mapping: Add internal shared allocation attribute
> dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free paths
> dma-pool: track decrypted atomic pools and select them via attrs
> dma: swiotlb: pass mapping attributes by reference
> dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
> dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHARED
> dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
> dma-direct: Move dma_direct_map_phys() to dma/direct.c
> dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
> dma-direct: set decrypted flag for remapped DMA allocations
> dma-direct: select DMA address encoding from
> __DMA_ATTR_ALLOC_CC_SHARED
> dma-direct: rename ret to cpu_addr in alloc helpers
> dma: swiotlb: free dynamic pools from process context
> dma: swiotlb: handle set_memory_decrypted() failures
> swiotlb: remove unused SWIOTLB_FORCE flag
>
> Documentation/core-api/dma-attributes.rst | 29 ++
> arch/arm64/mm/init.c | 5 +-
> arch/powerpc/platforms/pseries/cc_platform.c | 1 +
> arch/powerpc/platforms/pseries/svm.c | 2 +-
> arch/s390/Kconfig | 1 +
> arch/s390/mm/init.c | 17 +-
> arch/x86/kernel/amd_gart_64.c | 30 +-
> arch/x86/kernel/pci-dma.c | 4 +-
> drivers/iommu/dma-iommu.c | 20 +-
> drivers/xen/swiotlb-xen.c | 8 +-
> include/linux/dma-direct.h | 20 +-
> include/linux/dma-map-ops.h | 3 +-
> include/linux/dma-mapping.h | 8 +
> include/linux/swiotlb.h | 25 +-
> include/trace/events/dma.h | 3 +-
> kernel/dma/direct.c | 326 ++++++++++++++-----
> kernel/dma/direct.h | 56 +---
> kernel/dma/mapping.c | 25 +-
> kernel/dma/pool.c | 237 ++++++++++----
> kernel/dma/swiotlb.c | 292 +++++++++++++----
> 20 files changed, 810 insertions(+), 302 deletions(-)
>
> --
> 2.43.0
>
prev parent reply other threads:[~2026-07-28 14:22 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 18:04 [PATCH v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool() Aneesh Kumar K.V (Arm)
2026-07-21 11:54 ` Leon Romanovsky
2026-07-21 14:20 ` Aneesh Kumar K.V
2026-07-21 14:29 ` Leon Romanovsky
2026-07-21 15:10 ` Aneesh Kumar K.V
2026-07-21 15:33 ` Leon Romanovsky
2026-07-22 19:59 ` Jason Gunthorpe
2026-07-23 7:57 ` Leon Romanovsky
2026-07-25 14:34 ` Jason Gunthorpe
2026-07-26 8:17 ` Leon Romanovsky
2026-07-27 4:23 ` Jason Gunthorpe
2026-07-27 11:40 ` Leon Romanovsky
2026-07-28 12:31 ` Aneesh Kumar K.V
2026-07-28 14:24 ` Mostafa Saleh
2026-07-17 18:04 ` [PATCH v8 02/23] dma-pool: fix page leak in atomic_pool_expand() cleanup Aneesh Kumar K.V (Arm)
2026-07-21 12:31 ` Leon Romanovsky
2026-07-21 14:41 ` Aneesh Kumar K.V
2026-07-21 15:34 ` Leon Romanovsky
2026-07-17 18:04 ` [PATCH v8 03/23] iommu/dma: Check atomic pool allocation result directly Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 04/23] dma: free atomic pool pages by physical address Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 05/23] swiotlb: Preserve allocation virtual address for dynamic pools Aneesh Kumar K.V (Arm)
2026-07-28 14:25 ` Mostafa Saleh
2026-07-17 18:04 ` [PATCH v8 06/23] s390: Expose protected virtualization through cc_platform_has() Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 07/23] dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages Aneesh Kumar K.V (Arm)
2026-07-28 14:26 ` Mostafa Saleh
2026-07-17 18:04 ` [PATCH v8 08/23] coco: arm64: s390: powerpc: Mark secure guests with CC_ATTR_GUEST_MEM_ENCRYPT Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 09/23] dma-mapping: Add internal shared allocation attribute Aneesh Kumar K.V (Arm)
2026-07-28 14:25 ` Mostafa Saleh
2026-07-17 18:04 ` [PATCH v8 10/23] dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free paths Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 11/23] dma-pool: track decrypted atomic pools and select them via attrs Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 12/23] dma: swiotlb: pass mapping attributes by reference Aneesh Kumar K.V (Arm)
2026-07-28 14:41 ` Mostafa Saleh
2026-07-17 18:04 ` [PATCH v8 13/23] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 14/23] dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHARED Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 15/23] dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks Aneesh Kumar K.V (Arm)
2026-07-28 14:30 ` Mostafa Saleh
2026-07-17 18:04 ` [PATCH v8 16/23] dma-direct: Move dma_direct_map_phys() to dma/direct.c Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 17/23] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 18/23] dma-direct: set decrypted flag for remapped DMA allocations Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 19/23] dma-direct: select DMA address encoding from __DMA_ATTR_ALLOC_CC_SHARED Aneesh Kumar K.V (Arm)
2026-07-28 14:31 ` Mostafa Saleh
2026-07-17 18:04 ` [PATCH v8 20/23] dma-direct: rename ret to cpu_addr in alloc helpers Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 21/23] dma: swiotlb: free dynamic pools from process context Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 22/23] dma: swiotlb: handle set_memory_decrypted() failures Aneesh Kumar K.V (Arm)
2026-07-17 18:04 ` [PATCH v8 23/23] swiotlb: remove unused SWIOTLB_FORCE flag Aneesh Kumar K.V (Arm)
2026-07-21 12:40 ` [PATCH v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths Leon Romanovsky
2026-07-22 19:57 ` Jason Gunthorpe
2026-07-23 7:51 ` Leon Romanovsky
2026-07-25 14:32 ` Jason Gunthorpe
2026-07-25 7:09 ` Aneesh Kumar K.V
2026-07-28 14:22 ` Mostafa Saleh [this message]
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=ami7DMIlYHbcEt_6@google.com \
--to=smostafa@google.com \
--cc=Suzuki.Poulose@arm.com \
--cc=agordeev@linux.ibm.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.