On Wed, Jan 15, 2025 at 02:46:56PM +0100, Christian König wrote:[SNIP]
Yeah, but it's private to the exporter. And a very fundamental rule of DMA-buf is that the exporter is the one in control of things.I've said a few times now, I don't think we can build the kind of buffer sharing framework we need to solve all the problems with this philosophy. It is also inefficient with the new DMA API. I think it is backwards looking and we need to move forwards with fixing the fundamental API issues which motivated that design.
And that's what I clearly see completely different.
Those rules are not something we cam up with because of some limitation of the DMA-API, but rather from experience working with different device driver and especially their developers.
Applying and enforcing those restrictions is absolutely mandatory must have for extending DMA-buf.
So for example it is illegal for an importer to setup CPU mappings to a buffer. That's why we have dma_buf_mmap() which redirects mmap() requests from the importer to the exporter.Like this, in a future no-scatter list world I would want to make this safe. The importer will have enough information to know if CPU mappings exist and are safe to use under what conditions. There is no reason the importer should not be able to CPU access memory that is HW permitted to be CPU accessible. If the importer needs CPU access and the exporter cannot provide it then the attachment simply fails. Saying CPU access is banned 100% of the time is not a helpful position when we have use cases that need it.
That approach is an absolutely no-go from my side.
We have fully intentionally implemented the restriction that importers can't CPU access DMA-buf for both kernel and userspace without going through the exporter because of design requirements and a lot of negative experience with exactly this approach.
This is not something which is discuss-able in any way possible.
As far as I can see that is really not an use case which fits DMA-buf in any way.I really don't want to make a dmabuf2 - everyone would have to implement it, including all the GPU drivers if they want to work with RDMA. I don't think this makes any sense compared to incrementally evolving dmabuf with more optional capabilities.
The point is that a dmabuf2 would most likely be rejected as well or otherwise run into the same issues we have seen before.
That sounds more something for the TEE driver instead of anything DMA-buf should be dealing with.Has nothing to do with TEE.Why?The Linux TEE framework is not used as part of confidential compute. CC already has guest memfd for holding it's private CPU memory.
Where is that coming from and how it is used?
This is about confidential MMIO memory.
Who is the exporter and who is the importer of the DMA-buf in this use case?
This is also not just about the KVM side, the VM side also has issues with DMABUF and CC - only co-operating devices can interact with the VM side "encrypted" memory and there needs to be a negotiation as part of all buffer setup what the mutual capability is. :\ swiotlb hides some of this some times, but confidential P2P is currently unsolved.
Yes and it is documented by now how that is supposed to happen with DMA-buf.
As far as I can see there is not much new approach here.
Regards,
Christian.
Jason
