Re: [PATCH v6 7/9] dma-buf: system_heap: Enforce shared-granule alignment for cc-shared buffers

["Christian König" <christian.koenig@amd.com>]

On 9/21/26 14:17, Jason Gunthorpe wrote:
...
>>>> That userspace provides this cc_shared flag is a NO-GO to begin
>>>> with.
>>>
>>> What do you mean? We discussed this with the heap maintainers and we
>>> all agreed this was a kind of heap just like any of the other kinds of
>>> heaps that userspace can request.
>>>
>>> It is *exactly* the "special allocation requirements" you are talking
>>> about above.
>>
>> I only see a fraction of the patch set (because no DMA-buf
>> maintainer was CCed) and to me it looked like the cc_shared flag was
>> added as an additional parameter to the allocation and not a
>> separate heap created.
> 
> ?
> 
> It was merged months ago, and you were CC'd:
> 
> https://lore.kernel.org/all/20260325192352.437608-1-jiri@resnulli.us/

Ah! I though the flag was added in this patch set.

> 
> It follows the design the dma heaps maintiners guided to create a new
> named heap:
> 
> +	exp_info.name = "system_cc_shared";
> +	exp_info.priv = &system_heap_cc_shared_priv;
> 
> Along side the normal heap:
> 
>  	exp_info.name = "system";
> 
> It is identical to "system" except the pages are "CC shared" meaning
> the hypervisor and every DMA device can access them.
> 
> This series is just adjusting the rules around how
> set_memory_decrypted() works. It isn't changing any uAPI or adding
> anything new to dmabuf heaps.

Yeah that was absolutely not clear to me since I only got added to this single patch.

I also don't see where mem_cc_shared_granule_size is added?

> Yes, it ends up as a flag in the internal code flow, that is just how
> it got coded..

In that case this is probably ok as it is.

Christian.

> 
> Jason