Re: [PATCH v3 06/11] mm/cma: Allow dynamically creating CMA areas

On Thu, Jul 16, 2026 at 12:43:56PM +0200, Marek Szyprowski wrote:

On 09.07.2026 17:59, Thierry Reding wrote:

quoted

On Thu, Jul 09, 2026 at 07:56:45AM +0200, Marek Szyprowski wrote:

quoted

On 08.07.2026 10:35, David Hildenbrand (Arm) wrote:

quoted

On 7/7/26 12:02, Marek Szyprowski wrote:

quoted

On 01.07.2026 18:08, Thierry Reding wrote:

quoted

From: Thierry Reding <redacted>

There is no technical reason why there should be a limited number of CMA
regions, so extract some code into helpers and use them to create extra
functions (cma_create() and cma_free()) that allow creating and freeing,
respectively, CMA regions dynamically at runtime.

Well, the technical reason for not creating cma regions dynamically at
runtime is that on some architectures (like 32bit ARM) the early fixup
for the region is needed to make it functional for DMA.

Can you point me at the code that does that? Thanks!

Check dma_contiguous_early_fixup() and dma_contiguous_remap() in 
arch/arm/mm/dma-mapping.c. Those functions ensures that the CPU mappings for
the CMA reserved region in linear map are remapped with 4k pages instead
of the 1M sections, so later, it will be possible to alter the mappings and
change them to coherent when needed (altering 1M sections is not possible,
because each process has it's own level-1 array even for the kernel linear
mapping).



However, in the use case in this patchset the reserved region is only shared
with buddy allocator by using the CMA infrastructure, not registered to the
regular DMA-mapping API, so it would work fine. I'm not convinced that this
is the right API to use for this though.

Are you saying you're not convinced that CMA is the right API to use for
this? Or something else?

I read this again and indeed CMA seems to be right solution. I only wonder
why do You want to create the CMA areas dynamically? Imho it would work if
You just create large enough CMA area on boot, what would automatically
share the memory with buddy allocator and then allocate dynamic VPR regions
with cma_alloc(), potentially unmapping or marking the allocated region as
reserved in linear kernel mapping to avoid any potential speculative access
to the protected memory.

Hi Marek,

sorry for missing your reply earlier.

The reason why we want to create the CMA areas dynamically is because we
want to split the secure memory into multiple areas. And the size and
number of these areas may need to vary, so I didn't want to have to rely
on rebuilding kernels with different numbers of maximum CMA areas
depending on the chunk size that we choose.

The reason why we need to split up the protected memory into multiple
CMA areas is that allocation patterns can create holes within a CMA
area. For the VPR memory, however, we must ensure that there aren't any
holes within the protected region because it is specified using a single
base address and a size. So there is one contiguous region that can be
marked protected.

If we were to use a single CMA area, we could get holes within an area
that is marked protected and once the pages are returned to the buddy
allocator with cma_release(), something else could be attempting to
access it and cause an error because it is still protected.

The only way to make sure we get a single, resizable and contiguous
region is by using multiple CMA areas and allocating the entire area
once our allocations need to expand into that new area. So we're not in
fact using much of the CMA infrastructure and actually need to duplicate
some of it. We primarily need it for the page migration and reclaim
functionality.

In both cases You will probably won't need the DMA-mapping API on top of
it, although it might be even possible to partially use with by
registering custom dma_ops for the devices using the protected region
(assuming that it would support only DMA_ATTR_NO_KERNEL_MAPPING
allocations).

Yeah, I don't think we want the DMA API on top at all. The allocator has
special needs, like clustered allocations to minimize fragmentation and
keeping as few chunks activated as possible. We also want to avoid
resize operations because they can be quite heavy depending on system
load.

Thierry