From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 343894A64D3; Mon, 21 Sep 2026 14:50:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790002206; cv=none; b=p7NcfRTTyRWEm7aiVgdXut/kg55SkwEeDNsTVMy4Xv+032tOCo9/i3l9/7W9G5AraoeD6ATzJ/lX86a2i8DuFUSaGEc1UTBAGRPiR6DiVO0KGwkJIEmVOeSJTo0Oi4PYs/BZykETxF83ADWsNWCgWlXxsBsV60wfz6BRZ7W61UU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790002206; c=relaxed/simple; bh=xfg4l7aAPcFuNNw0eq2vq9ZJl7eqy9aAtKlDZYYEOu0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nMyrV+tgnd9CgPF4QZSE9TG++rGFbaMy95El4FPkkOGYXllRI0whOTB5f0IXnQfaZsscfBzuBtBjdX/G7zWU58h8SnXjEfXby2gnuHGt6mA0CxxyEJKPfBpX8rcWLFD/SNyYvlUc+Kt/Qj2hkgdboOURRaWDVHARyTP/INirnsQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GbU3J4YR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GbU3J4YR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 500401F000FF; Mon, 21 Sep 2026 14:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790002204; bh=J0RXC9wgCT9tCmz+jINf5SBQKcG/vPYAJMGd4hap8Yw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=GbU3J4YRMftmRU3jVFK0P2ygG00J8C4jBu4Ys1tpUN98glJT1tX1ZPswO6N6z6lAA WnjkUlnCLjFKCszyx2pEUTo3+5QIPTCs2doBtoVsBQS5mu/mREAiBQLWiXe4+wSLZm mSsfl5BK3UnuU6Gr3t60HLkoElNHWWH6WjIi93pYYLmUZ9v6tZ2mMB55GX6AZ/V3oV D18fKW95kPaoC7bvZrUyXgSyBqZrS8ScRtMvemwr2xSlV/oeZwfDMlmc1+pQMh3odX R0cR/d8No7rGW8ggtnjhCOriMqycOZC8UOGIZfaYntGncIiFOc+6D2M7lKuHb5IuR3 WekYxl0d0gA9g== From: "Aneesh Kumar K.V (Arm)" To: linux-coco@lists.linux.dev, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev Cc: "Aneesh Kumar K.V (Arm)" , Andrew Morton , Catalin Marinas , christian.koenig@amd.com, Jason Gunthorpe , Joerg Roedel , Marc Zyngier , Marek Szyprowski , Robin Murphy , Steven Price , Sumit Semwal , Suzuki K Poulose , Thomas Gleixner , Will Deacon , dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v7 07/13] dma-pool: Allocate CoCo atomic pools using CoCo shared memory allocator Date: Mon, 21 Sep 2026 20:18:41 +0530 Message-ID: <20260921144847.501151-8-aneesh.kumar@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260921144847.501151-1-aneesh.kumar@kernel.org> References: <20260921144847.501151-1-aneesh.kumar@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Atomic DMA allocations cannot perform a potentially sleeping private/shared state transition at allocation time. The atomic DMA pools avoid this by transitioning their backing allocations in a sleepable context and suballocating memory that is already shared. Architectures may require these transitions to use a shared granule size larger than PAGE_SIZE. The existing fallback loop can reduce the backing allocation below the order required by that size, producing a range that cannot be safely transitioned. For pools marked cc_shared, round the requested pool size up to a multiple of the shared granule size and prevent allocation fallback below the order required by that size. Pass this minimum order to dma_alloc_from_contiguous() as a required alignment so that CMA cannot silently clamp it. If CMA cannot satisfy the alignment, fall back to the buddy allocator. Non-shared pools pass zero and retain the existing CMA alignment policy. Use the cc_make_shared() and cc_make_private() helpers to transition the backing allocation and validate its address and size. Individual atomic allocations may remain smaller than the shared granule size because the backing allocation remains owned by the pool and in the shared state. Signed-off-by: Aneesh Kumar K.V (Arm) --- kernel/dma/pool.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c index 70b7f64b17ab..651d3a99c574 100644 --- a/kernel/dma/pool.c +++ b/kernel/dma/pool.c @@ -4,12 +4,12 @@ * Copyright (C) 2020 Google LLC */ #include +#include #include #include #include #include #include -#include #include #include #include @@ -85,6 +85,8 @@ static bool cma_in_zone(gfp_t gfp) static int atomic_pool_expand(struct dma_gen_pool *dma_pool, size_t pool_size, gfp_t gfp) { + struct cc_shared_layout layout; + unsigned int min_order = 0; unsigned int order; struct page *page = NULL; bool leak_pages = false; @@ -92,6 +94,16 @@ static int atomic_pool_expand(struct dma_gen_pool *dma_pool, size_t pool_size, int ret = -ENOMEM; pgprot_t prot __maybe_unused; + if (dma_pool->cc_shared) { + ret = cc_shared_calc_layout(pool_size, &layout); + if (ret) + goto out; + pool_size = layout.shared_size; + min_order = get_order(layout.alignment); + if (min_order > MAX_PAGE_ORDER) + return -E2BIG; + } + /* Cannot allocate larger than MAX_PAGE_ORDER */ order = min(get_order(pool_size), MAX_PAGE_ORDER); @@ -99,10 +111,10 @@ static int atomic_pool_expand(struct dma_gen_pool *dma_pool, size_t pool_size, pool_size = 1 << (PAGE_SHIFT + order); if (cma_in_zone(gfp)) page = dma_alloc_from_contiguous(NULL, 1 << order, - order, 0, false); + order, min_order, false); if (!page) page = alloc_pages(gfp | __GFP_NOWARN, order); - } while (!page && order-- > 0); + } while (!page && order-- > min_order); if (!page) goto out; @@ -126,8 +138,7 @@ static int atomic_pool_expand(struct dma_gen_pool *dma_pool, size_t pool_size, * shrink so no re-encryption occurs in dma_direct_free(). */ if (dma_pool->cc_shared) { - ret = set_memory_decrypted((unsigned long)page_to_virt(page), - 1 << order); + ret = cc_make_shared(page_to_virt(page), pool_size); if (ret) { leak_pages = true; goto remove_mapping; @@ -144,7 +155,7 @@ static int atomic_pool_expand(struct dma_gen_pool *dma_pool, size_t pool_size, encrypt_mapping: if (dma_pool->cc_shared && - set_memory_encrypted((unsigned long)page_to_virt(page), 1 << order)) + cc_make_private(page_to_virt(page), pool_size)) leak_pages = true; remove_mapping: -- 2.43.0