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

On 9/21/26 14:17, Jason Gunthorpe wrote:
...

quoted

quoted

quoted

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/ (local)

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