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

[Christian König]

On 9/21/26 13:51, Jason Gunthorpe wrote:
> On Mon, Sep 21, 2026 at 11:07:17AM +0200, Christian König wrote:
>> On 9/18/26 18:53, Jason Gunthorpe wrote:
>>> On Fri, Sep 18, 2026 at 05:39:55PM +0200, Christian König wrote:
>>>
>>>>> Arch code can figure out how to do it. If some ARM configs only give
>>>>> order 4 folios or whatever then dmabuf heap doesn't care.
>>>>
>>>> The fundamental problem is that DMA allocations are highly
>>>> architecture and device specific while Linux memory allocation APIs
>>>> are generic.
>>>
>>> This isn't a dma allocation, this is a memory allocation.
>>
>> No, I mean this is a DMA-buf heaps allocation. It is a DMA
>> allocation, we just don't know for which device.
> 
> So? How is it any different from the existing alloc pages?

That you need to specify that this is for DMA without encryption.

>> So ideally we should use resources which work for most devices in
>> the system.
> 
> Which this does.
> 
>> If a device has special allocation requirements (CMA,
>> restricted addressing etc...) we need a specialized DMA-buf heaps
>> for it.
> 
> Those things don't really intersect with CC, but if they did their are
> already heap names to request those, someone can add some shared
> restricted CMA option if they need someday ?
> 
>> 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.

If that is not the case then it is actually the correct approach.

Christian.

> 
> Jason