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

[Alexey Kardashevskiy <aik@amd.com>]

On 1/7/26 02:02, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 12:39:21PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 18/6/26 01:41, Jason Gunthorpe wrote:
>>> On Wed, Jun 17, 2026 at 10:50:39AM +1000, Alexey Kardashevskiy wrote:
>>>>> @@ -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.

>> 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