Alexey Kardashevskiy [off-list ref] writes:
On 4/6/26 18:39, Aneesh Kumar K.V (Arm) wrote:
quoted
Propagate force_dma_unencrypted() into DMA_ATTR_CC_SHARED in the
dma-direct allocation path and use the attribute to drive the related
decisions.
This updates dma_direct_alloc(), dma_direct_free(), and
dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.
Tested-by: Jiri Pirko <redacted>
Tested-by: Michael Kelley <redacted>
Tested-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/direct.c | 53 +++++++++++++++++++++++++++++++++++++--------
1 file changed, 44 insertions(+), 9 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index a741c8a2ee66..90dc5057a0c0 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -193,16 +193,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
bool remap = false, set_uncached = false;
- bool mark_mem_decrypt = true;
+ bool mark_mem_decrypt = false;
struct page *page;
void *ret;
+ /*
+ * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
+ * attribute. The direct allocator uses it internally after it has
+ * decided that the backing pages must be shared/decrypted, so the
+ * rest of the allocation path can consistently select DMA addresses,
+ * choose compatible pools and restore encryption on free.
Why this limit?
Context: I am looking for a memory pool for a few shared pages (to do
some guest<->host communication), SWIOTLB seems like the right fit but
swiotlb_alloc() is not exported and
dma_direct_alloc(DMA_ATTR_CC_SHARED) is not allowed. Thanks,
swiotlb is not the right pool to use for that, right?
CCA had a similar requirement for ITS pages and ended up creating a genpool:
b08e2f42e86b ("irqchip/gic-v3-its: Share ITS tables with a non-trusted hypervisor")
-aneesh