From: Jason Gunthorpe <jgg@nvidia.com>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Will Deacon <will@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Mike Rapoport <rppt@kernel.org>,
Pratyush Yadav <pratyush@kernel.org>,
Alexander Graf <graf@amazon.com>,
Robin Murphy <robin.murphy@arm.com>,
Kevin Tian <kevin.tian@intel.com>,
iommu@lists.linux.dev, kexec@lists.infradead.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Matlack <dmatlack@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pranjal Shrivastava <praan@google.com>,
Vipin Sharma <vipinsh@google.com>
Subject: Re: [RFC PATCH v2 00/10] dma-mapping: Add preservation of direct allocations
Date: Wed, 26 Aug 2026 15:31:12 -0300 [thread overview]
Message-ID: <20260826183112.GA3703145@nvidia.com> (raw)
In-Reply-To: <20260708234854.4044652-1-skhawaja@google.com>
On Wed, Jul 08, 2026 at 11:48:44PM +0000, Samiullah Khawaja wrote:
> This is an RFC v2 to discuss the preservation of DMA allocations for
> devices that are using direct allocation mode. Note preservation here
> means preservation of physical memory using KHO only. IOVAs and IOMMU
> mappings are out of scope.
>
> The complexity and need of this was discussed in the thread mentioned
> below. It was proposed to allow preservation of only a subset of
> allocations with minimum support. Offline discussion with Will Deacon
> concluded that this series is still needed, because we still want to use
> coherent allocations for Arm sMMUv3 ste/cds, so sending this v2.
Was this before or after concluding that ARM was OK with using
cachable memory?
> include/linux/dma-direct.h | 29 +++++
> include/linux/dma-map-ops.h | 10 ++
> include/linux/dma-mapping.h | 100 ++++++++++++++
> include/linux/kho/abi/dma_alloc.h | 32 +++++
> kernel/dma/Kconfig | 12 ++
> kernel/dma/Makefile | 1 +
> kernel/dma/coherent.c | 11 ++
> kernel/dma/contiguous.c | 27 ++++
> kernel/dma/direct.c | 189 +++++++++++++++++++++++++++
> kernel/dma/direct_test.c | 208 ++++++++++++++++++++++++++++++
> kernel/dma/mapping.c | 132 +++++++++++++++++++
> kernel/dma/pool.c | 17 +++
> 12 files changed, 768 insertions(+)
Because this seems like quite a big change to swallow compared to just
using iommu pages.h
Jason
next prev parent reply other threads:[~2026-08-26 18:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 23:48 [RFC PATCH v2 00/10] dma-mapping: Add preservation of direct allocations Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 01/10] dma: Add DMA allocation preservation KHO ABI Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 02/10] dma/pool: Add an API to check if DMA allocation is from pool Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 03/10] dma: contiguous: Add API to check if an allocation is from CMA Samiullah Khawaja
2026-07-15 6:21 ` Leon Romanovsky
2026-07-15 19:58 ` Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 04/10] dma-coherent: Allow checking if allocation is from dev coherent region Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 05/10] dma-direct: Add API to preserve/restore allocations Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 06/10] dma-mapping: Add API to preserve/restore DMA allocation Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 07/10] dma-mapping: Add support of preserving dmam allocations Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 08/10] dma: contiguous: Export is_from_cma helper for kunit Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 09/10] dma: pool: Export the is_from_pool " Samiullah Khawaja
2026-07-08 23:48 ` [RFC PATCH v2 10/10] dma-direct: Add KUnit test for liveupdate preservation Samiullah Khawaja
2026-08-26 18:31 ` Jason Gunthorpe [this message]
2026-09-18 16:27 ` [RFC PATCH v2 00/10] dma-mapping: Add preservation of direct allocations Will Deacon
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=20260826183112.GA3703145@nvidia.com \
--to=jgg@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=pasha.tatashin@soleen.com \
--cc=praan@google.com \
--cc=pratyush@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
--cc=vipinsh@google.com \
--cc=will@kernel.org \
/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.