Thread (77 messages) 77 messages, 6 authors, 2d ago

Re: [PATCH v6 03/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths

From: Alexey Kardashevskiy <hidden>
Date: 2026-07-02 00:25:42
Also in: linux-arm-kernel, linux-coco, linux-iommu, linux-s390, lkml


On 1/7/26 02:02, Jason Gunthorpe wrote:
On Thu, Jun 18, 2026 at 12:39:21PM +1000, Alexey Kardashevskiy wrote:
quoted

On 18/6/26 01:41, Jason Gunthorpe wrote:
quoted
On Wed, Jun 17, 2026 at 10:50:39AM +1000, Alexey Kardashevskiy wrote:
quoted
quoted
@@ -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,
Then setup your struct device so that the DMA API knows the
guest<->host channel requires unecrypted and it will work correctly.

I think this is a reasonable API to use for that, and I was just
advocating that hyperv should be using it too.

But it all relies on a properly setup struct device.
Sounds good but how do I do that in practice?
I think we haven't got there yet, I understood Dan's plan was to add a
bit in the struct device that signals if the device must be
unencrypted or can support all memory.

Currently the dma api assumes all devices must have unencrypted by
default so it should be fine already, shouldn't it?
It assumes that DMA returns a handle for shared memory but the state of that memory is not guaranteed beforehand. I dislike 2M page mashing.
quoted
not externally available so I'll have to trick the DMA layer into
using SWIOTLB (which is still all shared, right?) as I specifically
want to skip page conversions. Setting low DMA mask won't guarantee
that the DMA layer won't allocate a page outside of SWIOTLB and
convert it. Manually do
Why so particular?
aahhh I missed "pre-". I need a way to get pre-shared pages for my sev-guest activities.
Any address that satisifies the constraints should
be good enough?
Any address can be already shared (from swiotlb) or not (from outside swiotlb). The latter will may trigger 2M page smashing and this is what I want to avoid. Makes better sense now? Thanks,


-- 
Alexey

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help