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 DD10C46D572; Thu, 24 Sep 2026 10:07:35 +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=1790244462; cv=none; b=QMOClEN6lOY3QksNd9d2d3P9x7wKo6UM+8B7TxudCTJQMZbeRpnVhToF2JJAjcJZqPOaY7Li2y/TKD/9RkBwbx6dMnvlb2k+23vnEeK56L+yGlcF7YNmUuQWsrNw45OBdJwaFaGdfsB/G7zSw8Q2OeO5FaXrAMtaKRRauvc/XOE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790244462; c=relaxed/simple; bh=iuU84skys+c4t0D22DM1dXxzWja6PMh9eOBC2aAUPFQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NpvfoPz7tNENcjoA95k70q10/AectT4hYEQJX6Q5lBhKt0Wg234NOueO8rN/e/XQFZej5aQ0C6jfvwHxqJkmlkxpuPUnwKXAgl8KZB3ozDlEnHPFH2jGp/letJV7eOv6cP+OU/rtrkZXDdkZCzYSSBAsZdxrlMMszFMzDIt7kcE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LuTvXw7z; 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="LuTvXw7z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22E981F000FF; Thu, 24 Sep 2026 10:07:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790244451; bh=RaYIuvu7EWcx0kiHd4ySablfum8pI6JmFP40gOiNsBk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=LuTvXw7zqVNKQ4skqgavCDiVE8G/hbg2xCHYgmDtdbNSGuedcAsJXDvTuoJvyFscS EHVopMYcPM3szQABVqcGXam6pvpupTAuxZJ5OMb/ysSAaeYV5x2sPEAmgrokBcz319 dYSINIICwuHmGPzZo3FdmCMFjyVzDSjWZ7/OQPsSlFJtRW9vIYgiTi/RiOlSe+YkOQ a6oWvGFwJmhfYMS47NNaAbzFqfggPNWxhdZfbqWkcuua5X93I6ziIP4/QopgOCw9K3 JFpgHCo+ancimgLdB8OhxnkKJE1n9P4JeqUiS7vwniTX/Xfbe/7jZotMYGaxHKbxjB CGmucjMSnw+VQ== 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 , Baoquan He , Mike Rapoport , Pasha Tatashin , Pratyush Yadav , Catalin Marinas , =?UTF-8?q?Christian=20K=C3=B6nig?= , Jason Gunthorpe , Joerg Roedel , Marc Zyngier , Marek Szyprowski , Robin Murphy , Steven Price , Sumit Semwal , Suzuki K Poulose , Thomas Gleixner , Will Deacon , Russell King , Benjamin Gaignard , Brian Starkey , John Stultz , Mark Rutland , Radu Rendec , "T.J. Mercier" , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Ritesh Harjani , Shrikanth Hegde , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Kiryl Shutsemau , Rick Edgecombe , "K . Y . Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Paolo Bonzini , Vitaly Kuznetsov , Andy Lutomirski , Peter Zijlstra , dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v8 06/14] dma-pool: Allocate CoCo atomic pools using CoCo shared memory allocator Date: Thu, 24 Sep 2026 15:35:21 +0530 Message-ID: <20260924100529.1398790-7-aneesh.kumar@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260924100529.1398790-1-aneesh.kumar@kernel.org> References: <20260924100529.1398790-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 __DMA_ATTR_ALLOC_CC_SHARED to dma_alloc_from_contiguous() so it enforces the mandatory alignment. If CMA cannot satisfy it, fall back to the buddy allocator. Non-shared pools pass zero attributes 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. Cc: Marek Szyprowski Cc: Robin Murphy Assisted-by: Codex:gpt-5 Signed-off-by: Aneesh Kumar K.V (Arm) --- kernel/dma/pool.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c index 70b7f64b17ab..f059312c15aa 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,9 @@ 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 long attrs = 0; + unsigned int min_order = 0; unsigned int order; struct page *page = NULL; bool leak_pages = false; @@ -92,6 +95,17 @@ 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; + attrs = __DMA_ATTR_ALLOC_CC_SHARED; + } + /* Cannot allocate larger than MAX_PAGE_ORDER */ order = min(get_order(pool_size), MAX_PAGE_ORDER); @@ -99,10 +113,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, attrs, 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 +140,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 +157,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